[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-jiang-dhc-secure-dhcpv6) 00 01 02 03 04 05 06 07

DHC Working Group                                          Sheng Jiang
Internet Draft                            Huawei Technologies Co., Ltd
Intended status: Proposed Standard                           Sean Shen
Update: RFC3315                                                  CNNIC
Expires: March 17, 2013                             September 14, 2012

                        Secure DHCPv6 Using CGAs
                  draft-ietf-dhc-secure-dhcpv6-07.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 17, 2013.



Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Jiang & Shen           Expires March 17, 2013                 [Page 1]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012



Abstract

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
   DHCPv6 servers to pass configuration parameters. It offers
   configuration flexibility. If not secured, DHCPv6 is vulnerable to
   various attacks, particularly spoofing attacks. This document
   analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6
   mechanism based on using CGAs.



Table of Contents

   1. Introduction ................................................ 3
   2. Terminology ................................................. 3
   3. Security Overview of DHCPv6 ................................. 3
   4. Secure DHCPv6 Overview ...................................... 4
      4.1. New Components ......................................... 5
      4.2. Support for algorithm agility .......................... 5
   5. Extensions for Secure DHCPv6 ................................ 6
      5.1. CGA Parameter Option ................................... 6
      5.2. Signature Option ....................................... 7
      5.3. Signature Option for Relay-Reply Message ............... 9
      5.4. DUID-SA Type .......................................... 10
   6. Processing Rules and Behaviors ............................. 11
      6.1. Processing Rules of Sender ............................ 11
      6.2. Processing Rules of Receiver .......................... 12
      6.3. Processing Rules of Relay Agent ....................... 13
   7. Security Considerations .................................... 14
   8. IANA Considerations ........................................ 16
   9. Acknowledgments ............................................ 17
   10. References ................................................ 17
      10.1. Normative References ................................. 17
      10.2. Informative References ............................... 17















Jiang & Shen           Expires March 17, 2013                 [Page 2]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012



1. Introduction

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315])
   enables DHCPv6 servers to pass configuration parameters. It offers
   configuration flexibility. If not secured, DHCPv6 is vulnerable to
   various attacks, particularly spoofing attacks.

   This document analyzes the security issues of DHCPv6 in details. This
   document provides mechanisms for improving the security of DHCPv6:

      - the address of a DHCPv6 message sender, which can be a DHCPv6
        server, a relay agent or a client, can be verified by a
        receiver.

      - The integrity of DHCPv6 messages can be checked by the receiver
        of the message.

   The security mechanisms specified in this document is based on
   Cryptographically Generated Addresses (CGA [RFC3972]).

   Secure DHCPv6 is applicable in environments where physical security
   on the link is not assured (such as over wireless) and attacks on
   DHCPv6 are a concern.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. Security Overview of DHCPv6

   DHCPv6 is a client/server protocol that provides managed
   configuration of devices. It enables DHCPv6 server to automatically
   configure relevant network parameters on clients. In the basic DHCPv6
   specification [RFC3315], security of DHCPv6 message can be improved
   in a few aspects.

   a)   In the basic DHCPv6 specifications, the DHCPv6 server uses a
      "regular" IPv6 address for itself. It is possible for a malicious
      attacker to use a fake address to spoof or launch an attack. See
      Section 23, "Security Considerations" of [RFC3315] for more
      details.

      CGA-based security mechanism can provide proof of ownership of
      source addresses, which prevents such attacks.




Jiang & Shen           Expires March 17, 2013                 [Page 3]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   b)   The basic DHCPv6 specifications can optionally authenticate the
      origin of messages and validate the integrity of messages using an
      authentication option with a symmetric key pair. [RFC3315] relies
      on pre-established secret keys. For any kind of meaningful
      security, each DHCPv6 client would need to be configured with its
      own secret key; [RFC3315] provides no mechanism for doing this.

      For the key of the hash function, there are two key management
      mechanisms. Firstly, the key management is out of band, usually
      manual, i.e. operators set up key database for both server and
      client before running DHCPv6. Usually multiple keys are deployed
      one a time and key id is used to specify which key is used.

      Manual key distribution runs counter to the goal of minimizing the
      configuration data needed at each host. [RFC3315] provides an
      additional mechanism for preventing off-network timing attacks
      using the Reconfigure message: the Reconfigure Key authentication
      method. However, this method provides no message integrity or
      source integrity check. This key is transmitted in plaintext.

      Comparing to this, the CGA-based security mechanism only require a
      key pair on the sender. The key management mechanism is very
      simple.

   c)   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, which
      can be easier to deploy, is desirable.

4. Secure DHCPv6 Overview

   To solve the abovementioned security issues, we introduce the use of
   CGAs into DHCPv6. CGAs are introduced in [RFC3972]. By combining CGAs
   with signatures based on the CGA-associated key pair, address
   ownership can be verified and messages protected, "without a
   certification authority or any security infrastructure." [RFC3972]

   This document introduces a Secure DHCPv6 mechanism that uses CGAs to
   secure the DHCPv6 protocol. It assumes: the secured DHCPv6 message
   sender already has a CGA and its corresponding CGA parameters; and
   the receiver has already been have the CGAs of the sender, which may
   be pre-configured or recorded from previous communications; in the
   server-relay and relay-server scenarios, the receiver has also been
   pre-configured the associated CGA parameters of the sender.

   In this document, we introduce a CGA option with a mechanism for
   proving address ownership and two signature options with a
   corresponding verification mechanism. A DHCPv6 message (from a
   server, a relay agent or a client), with a CGA as source address and


Jiang & Shen           Expires March 17, 2013                 [Page 4]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   carry a digital signature, can be verified by the receiver for both
   the CGA and signature, then process the payload of the DHCPv6 message
   only if the validation is successful.

   This improves communication security of DHCPv6 messages. The
   authentication options can also be used for replay protection.

   Because the sender can be a DHCPv6 server, a relay agent or a client,
   the end-to-end security protection can be from DHCPv6 servers to
   relay agents or clients, or from clients to DHCPv6 servers. Relay
   agents MAY add its own Secure DHCPv6 options in Relay-Forward
   messages when transmitting client messages to the server.

4.1. New Components

   The components of the solution specified in this document are as
   follows:

      - CGAs are used to make sure that the sender of a DHCPv6 message
        is the "owner" of the claimed address. A public-private key
        pair has been generated by a node itself before it can claim an
        address. A new DHCPv6 option, the CGA Parameter Option, is used
        to carry the public key and associated parameters.

      - Signatures signed by private key protect the integrity of the
        DHCPv6 messages and authenticate the identity of their sender.

      - Server Address type of DUID is used to carry server's source
        address in the server-relay-client scenarios. The receiver gets
        the server's source CGA address for CGA verification.

4.2. Support for algorithm agility

   Hash functions are the fundamental security mechanism, including CGAs
   in this document. "...they have two security properties: to be one
   way and collision free." "The recent attacks have demonstrated that
   one of those security properties is not true." [RFC4270] It is
   theoretically possible to perform collision attacks against the
   "collision-free" property.

   Following the approach recommended by [RFC4270] and [NewHash], recent
   analysis shows none of these attacks are currently possible,
   according to [RFC6273]. "The broken security property will not affect
   the overall security of many specific Internet protocols, the
   conservative security approach is to change hash algorithms."
   [RFC4270]

   However, these attacks indicate the possibility of future real-world
   attacks. Therefore, we have to take into account that attacks will
   improved in the future, and provide a support for multiple hash


Jiang & Shen           Expires March 17, 2013                 [Page 5]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   algorithms. Our mechanism, in this document, supports not only hash
   algorithm agility but also signature algorithm agility.

   Support for hash agility within CGAs has been defined in [RFC4982].
   The usage of CGAs in this document SHOULD also obey [RFC4982], too.

   The support for algorithm agility in this document is mainly a
   unilateral notification model from a sender to a receiver. If the
   receiver cannot support the algorithm provided by the sender, it
   takes the risk itself. Senders in a same network do not have to
   upgrade to a new algorithm simultaneously.

5. Extensions for Secure DHCPv6

   This section extends DHCPv6. Three new options and a new DUID type
   have been defined. The new options MUST be supported in the Secure
   DHCPv6 message exchange. The new DUID type MUST be supported in 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)              .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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.




Jiang & Shen           Expires March 17, 2013                 [Page 6]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

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 the entire DHCPv6 header and
   options, particularly including the CGA option, except for the
   Signature option and the Authentication 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)                .
       .                                                               .
       .                                                     +-+-+-+-+-+
       |                                                     | Padding |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code     OPTION_SIGNATURE (TBA2).

       option-len      32 + Length of Signature field and Padding field
                       in octets.

       HA-id          Hash Algorithm id. The hash algorithm is used
                       for computing the signature result. This design
                       is adopted in order to provide hash algorithm
                       agility. The value is from the Hash Algorithm
                       for Secure DHCPv6 registry in IANA. The initial
                       values are assigned for SHA-1 is 0x0001.

       SA-id          Signature Algorithm id. The signature algorithm
                       is used for computing the signature result. This
                       design is adopted in order to provide signature
                       algorithm agility. The value is from the
                       Signature Algorithm for Secure DHCPv6 registry


Jiang & Shen           Expires March 17, 2013                 [Page 7]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

                       in IANA. The initial values are assigned for
                       RSASSA-PKCS1-v1_5 is 0x0001.

       HA-id-KH        Hash Algorithm id for Key Hash. Hash algorithm
                       used for producing the Key Hash field in the
                       Signature option. This design is adopted in
                       order to provide hash algorithm agility. The
                       value is from the Hash Algorithm for Secure
                       DHCPv6 registry in IANA. The initial values are
                       assigned for SHA-1 is 0x0001.

       Reserved        A 16-bit field reserved for future use. The
                       value MUST be initialized to zero by the sender,
                       and MUST be ignored by the receiver.

       Timestamp       The current time of day (NTP-format timestamp
                       [RFC5905], a 64-bit unsigned fixed-point number,
                       in seconds relative to 0h on 1 January 1900.).
                       It can reduce the danger of replay attacks.

       Key Hash        A 128-bit field containing the most significant
                       (leftmost) 128 bits of the hash value of the
                       public key used for constructing the signature.
                       The hash algorithm is indicated in the HA-id-KH
                       field. The field is taken over the presentation
                       used in the Public Key field of the CGA
                       Parameters data structure carried in the CGA
                       option. Its purpose is to associate the
                       signature to a particular key known by the
                       receiver. Such a key can either be stored in the
                       certificate cache of the receiver or be received
                       in the CGA option in the same message.

       Signature       A variable-length field containing a digital
                       signature. The signature value is computed with
                       the hash algorithm and the signature algorithm,
                       as described in HA-id and SA-id. The signature
                       constructed by using the sender's private key
                       protects the following sequence of octets:

                       1. The 128-bit CGA Message Type tag value for
                       Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090
                       0665 d2e0 02c2.

                       2. The 128-bit Source IPv6 Address.

                       3. The 128-bit Destination IPv6 Address.

                       4. The DHCPv6 message header.



Jiang & Shen           Expires March 17, 2013                 [Page 8]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

                       5. All DHCPv6 options except for the Signature
                       option and the Authentication Option.

                       6. The content between the option-len field and
                       the signature field in this Signature option, in
                       the format described above.

       Padding        This variable-length field contains padding, as
                       many bits long as remain after the end of the
                       signature. This padding is only needed if the
                       length of signature is not a multiple of 8
                       bits.

   Note: a Relay-Reply message is constructed by a DHCPv6 server in
   segments. The server first constructs the server message for client,
   which includes a Signature Option that covers the server message. In
   the signed data, the destination address is the address of the
   client. It then constructs the Relay-Reply message by encapsulating
   the server message into a Relay Message Option. If there is
   additional option for relay, the server MUST include a Signature
   Option for Relay-Reply Message, defined below, which covers the
   entire Relay-Reply message. In the signed data, the destination
   address is the address of the target relay agent.

5.3. Signature Option for Relay-Reply Message

   In the server-relay-client scenario, the Relay-Reply message may be
   carried two signatures: one covers the server message for client, one
   covers the entire relay-reply message. In order to save the double
   transmission of 32 byte duplicated data, which include HA-id, SA-id,
   SA-id-HK, Timestamp and Key Hash, another signature option is
   designed for Relay-Reply message only. On the receiver - the relay
   agent, these data can be obtained from the Signature Option within
   the Relay Message option. The format of the Signature Option for
   Relay-Reply message 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_RRM      |        option-len             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                    Signature (variable length)                .
       .                                                               .
       .                                                     +-+-+-+-+-+
       |                                                     | Padding |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code     OPTION_SIGNATURE_RRM (TBA3).



Jiang & Shen           Expires March 17, 2013                 [Page 9]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

       option-len      Length of Signature field and Padding field in
                       octets.

       Signature       The same with Section 5.3.

       Padding        The same with Section 5.3.

5.4. DUID-SA Type

   Server Address Type DUID (DUID-SA) allows IPv6 address of DHCPv6
   servers can be carried in DHCPv6 message payload.

   The following diagram illustrates the format of a DUID-SA:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             TBA3              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                     Server Address (128-bit)                  |
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type-code       DUID-SA Type (TBA4)

       Server Address   The 128-bit IPv6 address of the DHCPv6 server.

   The Server Address field of DUID-SA, which is the IPv6 address of the
   DHCPv6 server, MUST be a CGA in the Secure DHCPv6.

   In the server-relay-client scenarios, a DHCPv6 server knows a client
   is behind relay(s) if it receives a Relay-forward DHCPv6 message.
   Then it will reply a Relay-reply message. Within the payload of
   Replay-reply message, the server's source CGA address is carried in
   the Server Address Type DUID that is encapsulated in a Relay Message
   option. In this way, the receiver, a DHCPv6 client can get the
   server's source CGA address for CGA verification.

   All the payloads, including DUID-SA, are protected by signature
   option by the definition of section 5.1 and 5.2.

   If there is DUID-SA in the server message and its address is
   different from the source address of IP packet, the client MUST use
   the address in DUID-SA for CGA verification.






Jiang & Shen           Expires March 17, 2013                [Page 10]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

6. Processing Rules and Behaviors

6.1. Processing Rules of Sender

   The sender of a Secure DHCPv6 message could be a DHCPv6 server, a
   DHCPv6 relay agent or a DHCPv6 client.

   The node MUST have the following information in order to create
   Secure DHCPv6 messages:

       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.

   To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST
   construct the DHCPv6 message following the rules defined
   in [RFC3315]. The sender MUST use 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.

   A Secure DHCPv6 message MUST contain both the CGA option and the
   Signature option, except for the Relay-forward and Relay-reply
   Messages. If a relay agent adds its own options in Relay-forward
   message, it MUST contain the Signature option. If it does not any add
   new options it MUST NOT add either the CGA option or the Signature
   option into Relay-forward message. If a server adds addition options
   for relay agents in Relay-reply message, it MUST contain the
   Signature Option for Relay-Reply Message. If it does not add any
   addition options, it MUST NOT add the CGA option, the Signature
   option, or the Signature Option for Relay-Reply Message into the
   Relay-reply message.

   The CGA option is constructed according to the rules presented in
   Section 5.1 and in [RFC3972]. The public key in the field is the one
   associated with the CGA, which is also the source address in the
   message header.

   The Signature option MUST be constructed as explained in Section 5.2.
   It protects the message header and the message payload and all DHCPv6
   options (including the CGA option) except for the Signature option
   itself and the Authentication Option. The Signature Option for
   Relay-Reply Message MUST be constructed as explained in Section 5.3.




Jiang & Shen           Expires March 17, 2013                [Page 11]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   When constructing a Relay-reply message, a DHCPv6 server MUST include
   an OPTION_SERVERID [RFC3315] and put its CGA in the Server Address
   field of the DUID in the OPTION_SERVERID in the Relay Message Option.
   By applying this rule, the CGA of the DHCPv6 server will not be lost
   when the relay agents decapsulate the Relay-reply messages, so that
   the client can verify CGA address and signature.

6.2. Processing Rules of Receiver

   When receiving a DHCPv6 message (except for Relay-Forward and
   Relay-Reply messages), a Secure DHCPv6 enabled receiver SHOULD
   discard the DHCPv6 message if either the CGA option or the Signature
   option is absent. If both options are absent, the receiver MAY fall
   back the unsecure DHCPv6 model.

   The receiving node MUST verify the source CGA address of the DHCPv6
   message by using the public key of the DHCPv6 message sender, CGA
   Parameters and the algorithm described in Section 5 of [RFC3972]. The
   inputs to the algorithm are the source address, as used in IPv6
   header, and the CGA Parameters field. 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.

   If the CGA verification is successful, the recipient proceeds with a
   more time-consuming cryptographic check of the signature. Note that
   even if the CGA verification succeeds, no claims about the validity
   of the use can be made until the signature has been checked.

   The receiving node MUST verify the Signature option as follows: the
   Key Hash field MUST indicate the use of a known public key, the one
   learned from a preceding CGA option in the same message. The
   signature field verification MUST show that the signature has been
   calculated as specified in Section 5.2.

   Only the messages that get through both CGA and signature
   verifications are accepted as secured DHCPv6 messages and continue to
   be handled for their contained DHCPv6 options as defined
   in [RFC3315]. Messages that do not pass all the above tests MUST be
   discarded or treated as unsecure messages.

   The receiver MAY record the verified CGA for future authentications.

   Furthermore, the node that supports the verification of the Secure
   DHCPv6 messages MAY record the following information:

       Minbits        The minimum acceptable key length for public
                       keys used in the generation of CGAs. An upper
                       limit MAY also be set for the amount of


Jiang & Shen           Expires March 17, 2013                [Page 12]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

                       computation needed when verifying packets that
                       use these security associations. The appropriate
                       lengths SHOULD be set according to the signature
                       algorithm and also following prudent
                       cryptographic practice. For example, minimum
                       length 1024 and upper limit 2048 may be used for
                       RSA [RSA].

   A Relay-forward message without any addition option to Relay Message
   option or a Relay-forward message with both addition options and the
   Signature option is accepted for a Secure DHCPv6 enabled server.
   Otherwise, the message SHOULD be discarded or treated as unsecure
   message. If Signature option is presented in the Relay-forward
   message, the CGA verification and signature verification are needed.
   The server obtains the CGA parameters of the relay agents from
   pre-configured data. The server MUST also verify the CGA and
   signature for the encapsulated client DHCPv6 message in the Relay
   Message Option. The client CGA address is obtained from the
   peer-address field in the Relay-forward message.

   A Relay-reply message without any addition option to Relay Message
   option or a Relay-reply message with both addition options and the
   Signature Option for Relay-Reply message is accepted for a Secure
   DHCPv6 enabled server. Otherwise, the message SHOULD be discarded or
   treated as unsecure message. If the Signature Option for Relay-Reply
   message is presented in the Relay-reply message, the CGA verification
   and signature verification are needed. The relay agents obtain the
   CGA parameters of the server from pre-configured data. It obtains
   HA-id, SA-id, SA-id-HK, Timestamp and Key Hash from Signature option
   encapsulated in the Relay Message option.

6.3. Processing Rules of Relay Agent

   To support Secure DHCPv6, relay agents MUST follow the same
   processing rules defined in [RFC3315].

   In the client-relay-server scenario, the relay agent MAY verify the
   CGA and signature as a receiver before relaying the client message
   further, following verification procedure define in Section 6.2. In
   the case of failure, it MUST discard the DHCPv6 message. However,
   this does not save the load of the DHCPv6 server. The server still
   MUST verify the CGA and signature by itself in order to prevent the
   attack between the relay agent and server.

   In the server-relay-client scenario, if the Signature Option for
   Relay-Reply message is presented, the relay agent MUST verify the CGA
   and signature before relaying the server message further, following
   verification procedure define in Section 6.2. In the case of failure,
   it MUST discard the DHCPv6 message.



Jiang & Shen           Expires March 17, 2013                [Page 13]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   In the relay scenarios, because relay agents restructure the DHCPv6
   messages, a downstream receiver would not find the sender's source
   CGA address in the DHCPv6 message header.

   In the client-relay-server scenarios, "The relay agent copies the
   source address from the IP datagram in which the message was received
   from the client into the peer-address field in the Relay-forward
   message" [RFC3315]. Therefore, the CGA of a client will not be lost
   during the relay processing from the client to the server. The
   receiver, a DHCPv6 server, can find the sender's source CGA address
   in the peer-address field for CGA verification.

   During the relay processing from the server to the client, when the
   relay agent constructs the IPv6 header for the server message, the
   source IPv6 address is the relay's IPv6 address, rather than the
   server's IPv6 address. In order to make the CGA of the DHCPv6 server
   reach the client, DUID-SA, described in Section 5.4, MUST be used.
   Defined in [RFC6422], "the implicit requirement that relay agents not
   modify the content of encapsulation payloads as they are relayed back
   toward clients", A relay agent will not change the OPTION_SERVERID
   when processing Relay-reply message from a DHCPv6 server, so that the
   CGA of the DHCPv6 server will not be lost when the Relay-reply
   message is decapsulated in the relay agent. The relay agent MAY also
   verify the CGA and signature for the encapsulated DHCPv6 message in
   the Relay Message Option. This can be helpful if the DHCPv6 response
   traverses a separate administrative domain, or if the relay agent is
   in a separate administrative domain. However, this is not necessary
   because the DHCPv6 client validation will catch any modification to
   the response.

7. Security Considerations

   This document provides new security features to the DHCPv6 protocol.

   Using CGA as source addresses with its verification mechanism in
   DHCPv6 message exchanging provides the source address ownership
   verification and data integrity protection.

   The Secure DHCPv6 mechanism is based on the pre-condition that the
   receiver knows the CGA of senders. For example, to prevent DHCPv6
   server spoofing, the clients should be pre-configured with the DHCPv6
   server CGA. The clients may decline the DHCPv6 messages from unknown
   servers, which may be fake servers; or may prefer DHCPv6 messages
   from known servers over unsigned messages or messages from unknown
   servers. The pre-configuration operation also needs to be protected,
   which is out of scope.

   In the relay-server and server-relay authentication scenarios, the
   Secure DHCPv6 mechanism is based on the pre-condition that the
   receiver has been pre-configured with sender's CGAs and associated


Jiang & Shen           Expires March 17, 2013                [Page 14]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   CGA parameters. The pre-configuration operation also needs to be
   protected, which is out of scope.

   CGA-based signatures cannot be used to authenticate a transaction if
   the CGA key isn't pre-configured in the DHCPv6 client that needs to
   authenticate the transaction. However, such a DHCPv6 client can make
   a leap of faith when it first encounters a new CGA. If the DHCPv6
   server that used that CGA is in fact legitimate, then all future
   communication with that DHCPv6 server can be protected by caching the
   CGA and the associated public key. This does not provide complete
   security, but it limits the opportunity to mount an attack on a
   specific DHCPv6 client to the first time it communicates with a new
   DHCPv6 server.

   DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific
   addresses cannot be protected.

   Downgrade attacks cannot be avoided if nodes are configured to accept
   both secured and unsecured messages. A future specification may
   provide a mechanism on how to treat unsecured DHCPv6 messages.

   As stated in CGA definition [RFC3972], link-local CGAs are more
   vulnerable because the same prefix is used by all IPv6 nodes.
   Therefore, when link-local CGAs are used by the DHCPv6 clients, it is
   recommended to use a slightly higher Sec value, for example Sec=1 for
   now. When higher Sec values are used, the relative advantage of
   attacking link-local addresses becomes insignificant.

   Impacts of collision attacks on current uses of CGAs are analyzed in
   [RFC4982]. The basic idea behind collision attacks, as described in
   Section 4 of [RFC4270], is on the non-repudiation feature of hash
   algorithms. However, CGAs do not provide non-repudiation features.
   Therefore, as [RFC4982] points out CGA-based protocols, including
   Secure DHCPv6 defined in this document, are not affected by collision
   attacks on hash functions.

   [RFC6273] has analyzed possible threats to the hash algorithms used
   in SEND. Since the Secure DHCPv6 defined in this document uses the
   same hash algorithms in similar way to SEND (except that Secure
   DHCPv6 has not used PKIX Certificate), analysis results could be
   applied as well: current attacks on hash functions do not constitute
   any practical threat to the digital signatures used in the signature
   algorithm in the Secure DHCPv6. Attacks on CGAs, as described in
   [RFC4982], will compromise the security of Secure DHCPv6 and they
   need to be addressed by encoding the hash algorithm information into
   the CGA as specified in [RFC4982].






Jiang & Shen           Expires March 17, 2013                [Page 15]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

8. IANA Considerations

   This document defines two new DHCPv6 [RFC3315] options, which MUST be
   assigned Option Type values within the option numbering space for
   DHCPv6 messages:

       The CGA Parameter Option (TBA1), described in Section 5.1.

       The Signature Option (TBA2), described in Section 5.2.

       The Signature Option for Relay-Reply Message (TBA3), described in
       Section 5.3.

   This document defines a new DHCPv6 DUID, which MUST be assigned DUID
   Type values within the DHCPv6 DUID Type numbering space:

      The DUID-SA (TBA4), described in Section 5.4.

   This document defines two new registries that have been created and
   are maintained by IANA. Initial values for these registries are given
   below. Future assignments are to be made through Standards Action
   [RFC5226]. Assignments for each registry consist of a name, a value
   and a RFC number where the registry is defined.

   Hash Algorithm for Secure DHCPv6. The values in this name space are
   16-bit unsigned integers. The following initial values are assigned
   for Hash Algorithm for Secure DHCPv6 in this document:

             Name        |  Value  |  RFCs
      -------------------+---------+------------
            Reserved     |  0x0000 | this document
            SHA-1        |  0x0001 | this document
            SHA-256      |  0x0002 | this document

   Signature Algorithm for Secure DHCPv6. The values in this name space
   are 16-bit unsigned integers. The following initial values are
   assigned for Signature Algorithm for Secure DHCPv6 in this document:

             Name        |  Value  |  RFCs
      -------------------+---------+------------
            Reserved     |  0x0000 | this document
       RSASSA-PKCS1-v1_5 |  0x0001 | this document

   This document defines a new 128-bit value under the CGA Message Type
   [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2.
   (The tag value has been generated randomly by the editor of this
   specification. It may replaced by any IANA-allocated value when the
   specification is published.)




Jiang & Shen           Expires March 17, 2013                [Page 16]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

9. Acknowledgments

   The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms,
   Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher
   and other members of the IETF DHC and CSI working groups for their
   valuable comments.

10. References

10.1. Normative References

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC3315, July 2003.

   [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
             March 2005.

   [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms
             in Cryptographically Generated Addresses (CGAs)", RFC4982,
             July 2007.

   [RFC5905] D. Mills, J. Martin, Ed., J. Burbank and W. Kasch, "Network
             Time Protocol Version 4: Protocol and Algorithms
             Specification", RFC 5905, June 2010.

   [RFC6422] T. Lemon, and Q. Wu, "Relay-Supplied DHCP Options", RFC
             6422, December 2011.

10.2. Informative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", c, March 1997.

   [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
             Hashes in Internet Protocols", RFC 4270, November 2005.

   [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", RFC 5226, May 2008.

   [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor
             Discovery (SEND) Hash Threat Analysis", RFC 6274, June
             2011.

   [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash
             Algorithm", November 2005.

   [RSA]    RSA Laboratories, "RSA Encryption Standard, Version 2.1",
             PKCS 1, November 2002.




Jiang & Shen           Expires March 17, 2013                [Page 17]


Internet-Draft     draft-ietf-dhc-secure-dhcpv6-07      September 2012

   [sha-1]  National Institute of Standards and Technology, "Secure
             Hash Standard", FIBS PUB 180-1, April 1995,
             http://www.itl.nist.gov/fipspubs/fip180-1.htm.



   Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China
   EMail: jiangsheng@huawei.com

   Sean Shen
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   EMail: shenshuo@cnnic.cn





























Jiang & Shen           Expires March 17, 2013                [Page 18]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/