Network Working Group Sheng Jiang Sean Shen Internet Draft Huawei Technologies Co., Ltd Expires: January 2009 July 4th, 2008 Secure DHCPv6 Using CGAs draft-jiang-dhc-secure-dhcpv6-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 January 3rd, 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. Jiang Expires January 2, 2008 [Page 1] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 Table of Contents 1. Introduction................................................2 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. 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 Intellectual Property Statement................................13 Disclaimer of Validity........................................14 Copyright Statement...........................................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. This document analyzes the security issues of DHCPv6. 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. Jiang & Shen Expires January 2, 2009 [Page 2] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 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. Jiang & Shen Expires January 2, 2009 [Page 3] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 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-config]. Jiang & Shen Expires January 2, 2009 [Page 4] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 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: Jiang & Shen Expires January 2, 2009 [Page 5] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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. 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 DHCPv6 messages. The Signature option SHOULD be the last option in order to protect all DHCPv6 options. Any options after the Signature option will be ignored. The format of the Signature option is described as follows: Jiang & Shen Expires January 2, 2009 [Page 6] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 January 2, 2009 [Page 7] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 January 2, 2009 [Page 8] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 January 2, 2009 [Page 9] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 [RFC3974]. 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 January 2, 2009 [Page 10] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 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 [RFC2434]. 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 January 2, 2009 [Page 11] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 9. References 9.1. Normative References [RFC1305] D. Mills, "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC1305, March, 1992. [RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, March 2005. [RFC4270] P. Hoffman, B. Schneier, "Attacks on Cryptographic Hashed in Internet Protocols", RFC 4270, November 2005. [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC4982, July 2007. [CGA-Conf]S.Jiang, et al., "Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based solutions", working in progress. [new-hashes] S.Bellovin, E. Rescorla, "Deploying a New Hash Algorithm", November 2005. [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, . 9.2. Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, April 1998. Jiang & Shen Expires January 2, 2009 [Page 12] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 Author's Addresses Sheng Jiang 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-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 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jiang & Shen Expires January 2, 2009 [Page 13] Internet-Draft draft-jiang-dhc-secure-dhcpv6-00.txt July 2008 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Jiang & Shen Expires January 2, 2009 [Page 14]