Network Working Group                                     Sheng Jiang
Internet Draft                                              Sean Shen
Intended status: Standards Track          Huawei Technologies Co., Ltd
Expires: July 12, 2009                               January 8th, 2009

                        Secure DHCPv6 Using CGAs
                  draft-jiang-dhc-secure-dhcpv6-01.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 July 14, 2009.



Abstract

   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.



Table of Contents

   1. Introduction................................................2
   2. Terminology.................................................2
   3. Security Overview of DHCPv6..................................3
   4. Secure DHCPv6 Overview.......................................4



Jiang                  Expires July 14, 2009                 [Page 1]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


      4.1. New Components.........................................4
      4.2. Support for algorithm agility...........................5
   5. Secure DHCPv6 Options........................................5
      5.1. CGA Parameter Option....................................5
      5.2. Signature Option........................................6
   6. Processing Rules and Behaviors...............................9
      6.1. Processing Rules of Sender..............................9
      6.2. Processing Rules of Receiver............................9
   7. Security Considerations.....................................10
   8. IANA Considerations........................................11
   9. References.................................................12
      9.1. Normative References...................................12
      9.2. Informative References.................................12
   Author's Addresses............................................13
   Copyright Notice..............................................14



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 [PS-DC]. 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 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.

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].




Jiang & Shen            Expires July 12, 2009                 [Page 2]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


3. Security Overview of DHCPv6

   DHCPv6 is a client/server protocol that provides managed and stateful
   configuration of devices. It enables DHCPv6 server to auto-configure
   relevant network parameters on clients through the DHCPv6 message
   exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315],
   security of DHCPv6 message can be improved in a few aspects.

   In the basic DHCPv6 specifications, regular IPv6 addresses are used.
   It is possible for a malicious attacker to use a fake address to
   spoof or launch an attack.

   "One attack specific to a DHCP client is the establishment of a
   malicious server with the intent of providing incorrect configuration
   information to the client. The motivation for doing so may be to
   mount a 'man in the middle' attack that causes the client to
   communicate with a malicious server instead of a valid server for
   some service such as DNS or NTP. The malicious server may also mount
   a denial of service attack through mis-configuration of the client
   that causes all network communication from the client to fail."
   [RFC3315]

   "A DHCP client may also be subject to attack through the receipt of a
   Reconfigure message from a malicious server that causes the client to
   obtain incorrect configuration information from that server."
   [RFC3315]

   Fake servers can also provide clients with partially correct
   information that allows the attacker to route traffic through certain
   host where critical information can be collected. This becomes
   important to detect and prevent when encrypted traffic is allowed to
   pass through firewalls. Clients can be configured with bogus data, so
   that they will assume that the network is down.

   Once servers start updating DNS and other directory services,
   attackers may spoof DHCP servers to register incorrect information in
   those services.

   Another possible attack is that attackers may be able to gain
   unauthorized access to some resources, such as network access.

   The basic DHCPv6 specifications achieve message origin authentication
   and message integrity via an authentication option with a symmetric
   key pair. 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


Jiang & Shen            Expires July 12, 2009                 [Page 3]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


   once a time and key id is used to specify which key is used. Secondly,
   a DHCPv6 server sends a reconfigure key to the client in the initial
   exchange of DHCPv6 messages for future use, in this case security is
   not guaranteed because this key is transmitted in plaintext. In
   either way, the security of key itself is in question mark.

   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
   ability. Furthermore, the manual configuration and static keys are
   potential issue makers. Relay agents may require other security
   mechanisms besides IPSec.

4. Secure DHCPv6 Overview

   To solve the abovementioned security issues, we introduce CGAs into
   DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses
   for which the interface identifier is generated by computing a
   cryptographic one-way hash function from a public key and auxiliary
   parameters. The binding between the public key and the address can be
   verified by re-computing the hash value and by comparing the hash
   with the interface identifier. Messages sent from an IPv6 address can
   be protected by attaching the public key and auxiliary parameters and
   by signing the message with the corresponding private key. The
   protection works without a certification authority or any security
   infrastructure."

   In this document, a CGA option with an address ownership proof
   mechanism and a signature option with a corresponding verification
   mechanism are introduced. With them, the receiver of a DHCP message
   can verify the sender address of the DHCP message, which improves
   communication security of DHCP messages. By using the signature
   option, the verification of data integrity and replay protections can
   also be achieved without the authentication option.

   This documentation focuses on using CGAs to secure the DHCPv6
   protocol. It assumes the sender, which uses CGAs, has self-generated
   or been configured CGAs. The CGA configuration in the DHCPv6 network
   is out of scope and specified in [CGA-Conf].

4.1. New Components

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




Jiang & Shen            Expires July 12, 2009                 [Page 4]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


      - 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 or configured before
        it can claim an address. A new DHCPv6 option, the CGA Parameter
        Option, is used to carry the public key and associated
        parameters.

      - Public key signatures protect the integrity of the messages and
        authenticate the identity of their sender. The authority of a
        public key is established either with the authorization
        delegation process, by using certificates, or through the
        address ownership proof mechanism, by using CGAs, or with both.

4.2. Support for algorithm agility

   Hash functions are the fundamental of security mechanisms, 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]

   Following the approach recommended by [RFC4270] and [new-hashes], our
   analysis shows none of these attacks are currently doable. However,
   these attacks indicate the possibility of future real-world attacks.
   Therefore, we have to take into account that future attacks will be
   improved and provide a support for multiple hash algorithms. Our
   mechanisms, in this document, support not only hash algorithm agility
   but also signature algorithm agility.

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

5. Secure DHCPv6 Options

   The options defined in this section MUST be supported, if the node
   has been configured to use Secure DHCPv6.

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              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Jiang & Shen            Expires July 12, 2009                 [Page 5]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


       |                                                               |
       .                                                               .
       .                 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. 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:

















Jiang & Shen            Expires July 12, 2009                 [Page 6]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


        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)                .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code     OPTION_SIGNATURE (TBA2).

       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.

       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.

       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.


Jiang & Shen            Expires July 12, 2009                 [Page 7]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


       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
                       [RFC1305], 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 a SHA-1 hash of the
                       public key used for constructing the signature.
                       The SHA-1 hash 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
                       over 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. (The tag value has been
                       generated randomly by the editor of this
                       specification.).

                       2. The 128-bit Source Address field from the IP
                       header.

                       3. The 128-bit Destination Address field from
                       the IP header.

                       4. The DHCPv6 message header.

                       5. All DHCPv6 options preceding the Signature
                       option.

                       6. The content between the option-len field and



Jiang & Shen            Expires July 12, 2009                 [Page 8]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


                       the signature field in this Signature option, in
                       the format described above.

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.

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
                       needed when verifying packets that use these
                       security associations. Any implementation should
                       follow prudent cryptographic practice in
                       determining the appropriate key lengths.


Jiang & Shen            Expires July 12, 2009                 [Page 9]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


   On a node that has been configured to use Secure DHCPv6, DHCPv6
   message without either the CGA option or the Signature option MUST be
   treated as unsecured. Note the Secure DHCPv6 nodes MAY simply discard
   the unsecured messages.

   The receiving node MUST verify the source address of the packet by
   using the algorithm described in Section 5 of [RFC3972]. The inputs
   to the algorithm are the source address, as used in IP header, and
   the CGA Parameters field.

   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
   receiver MUST ignore any options that come after the Signature option.
   The Key Hash field MUST indicate the use of a known public key,
   either one learned from a preceding CGA option in the same message,
   or one known by other means. The signature field verification MUST
   show that the signature has been calculated as specified in the
   previous section.

   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.

   Messages that do not pass all the above tests MUST be silently
   discarded if the host has been configured to accept only secured
   DHCPv6 messages. The messages MAY be accepted if the host has been
   configured to accept both secured and unsecured messages but MUST be
   treated as an unsecured message. The receiver MAY also otherwise
   silently discard packets.

7. Security Considerations

   This document provides new security features to the DHCPv6 protocol.

   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. One
   simple solution may be that Secure DHCPv6 is mandated on all servers,
   reply agents and clients if a certain link has been deployed Secure
   DHCPv6.


Jiang & Shen            Expires July 12, 2009                [Page 10]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


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.

   This document defines three 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 id(HA-id). The values in this name space are 16-bit
   unsigned integers. The following initial values are assigned for HA-
   id in this document:

             Name        |  Value  |  RFCs
      -------------------+---------+------------
            SHA-1        |  0x0000 | this document

   Signature Algorithm (SA-id). The values in this name space are 16-bit
   unsigned integers. The following initial values are assigned for SA-
   id in this document:

             Name        |  Value  |  RFCs
      -------------------+---------+------------
            SHA-1        |  0x0000 | this document

   Hash Algorithm id for Key Hash (HA-id-KH). The values in this name
   space are 16-bit unsigned integers. The following initial values are
   assigned for HA-id-KH in this document:

             Name        |  Value  |  RFCs
      -------------------+---------+------------
       RSASSA-PKCS1-v1_5 |  0x0000 | 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.







Jiang & Shen            Expires July 12, 2009                [Page 11]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


9. References

9.1. Normative References

   [RFC1305] D. Mills, "Network Time Protocol (Version 3) Specification,
             Implementation and Analysis", RFC1305, March, 1992.

   [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.

9.2. Informative References

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

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

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

   [new-hashes]     S.Bellovin, E. Rescorla, "Deploying a New Hash
             Algorithm", November 2005.

   [CGA-Conf] S.Jiang, et al., "Requirements for configuring
             Cryptographically Generated Addresses (CGA) and overview on
             RA and DHCPv6-based solutions", draft-jiang-sendcgaext-cga-
             config-02, working in progress, July 2008.

   [PS-DC]  S. Jiang, "DHCPv6 and CGA Interaction: Problem Statement",
             draft-jiang-csi-dhcpv6-cga-ps-01.txt, work in progress,
             January 2009.

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

   [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>.



Jiang & Shen            Expires July 12, 2009                [Page 12]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Phone: 86-10-82836774
   Email: shengjiang@huawei.com

   Sean Shen
   Huawei Technologies Co., Ltd
   QuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, P.R. China
   100085
   Phone: 86-10-82836072
   Email: sshen@huawei.com






























Jiang & Shen            Expires July 12, 2009                [Page 13]


Internet-Draft  draft-jiang-dhc-secure-dhcpv6-01.txt      January 2009


Copyright Notice

   Copyright (c) 2009 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.





































Jiang & Shen            Expires July 12, 2009                [Page 14]