Network Working Group H.Rafiee INTERNET-DRAFT D. Zhang Updates RFC 3972 (if approved) Huawei Technologies Intended Status: Standards Track Expires: February 11, 2015 August 11, 2014 CGA Security Improvement Abstract This document addresses the security problems existing in the current CGA specification. It also explain the changes that is needed to take into consideration when the prefix length needs to be variable. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." This Internet-Draft will expire on February 11, 2015. Copyright Notice Copyright (c) 2014 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 Rafiee & Zhang Expires February 11, 2015 [Page 1] INTERNET DRAFT CGA bisAugust 11, 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sec Value Solution . . . . . . . . . . . . . . . . . . . . . 3 3. CGA and Challenges in Variable Length Prefix . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Rafiee & Zhang Expires February 11, 2015 [Page 2] INTERNET DRAFT CGA bis August 11, 2014 1. Introduction In the Cryptographically Generated Addresses (CGA) specification [RFC3972], the 64 rightmost bits of an IPv6 address is securely generated with a public key. This solution is able to provides the proof of IP address ownership and then prevent source IP spoofing by finding a binding between the public key and the node's IP address. Unfortunately, during the verification step as explained in [cga-attack], the verifier nodes ignore the 3 bits sec value in the interface ID (IID) and there is no check between the source and target IP address. This problem lead to the case where an attacker can calculate a new CGA address which is identical to the address of the victim node except its sec value field is zero. This document tries to explain how to address this problem. This document also tries to explain how CGA specification needs to be changed when it is expected to support variable prefix. 2. Sec Value Solution Sec value in CGA algorithm is the value between 0 to 7. This value shows the strengthen of the algorithm against brute-force attacks. As higher this value is, the more expensive and complicated the algorithm is for the attacker. As explained in [cga-attack], since there is no check between the source and target addresses and the node ignores 3 bits sec values during verification process, an attacker can try to perform brute-force attacks without being detected. In other words, it does not matter what sec value the legitimate node uses, the attacker can always generate a new CGA address identical to the address of the victim except of the sec value field, and use the address to impersonate the legal node without being detected. To address this problem, we propose the changes in the following section of RFC 3972: - Section 5. new step MUST be placed before step 1 of verification. 1- If the sender's source address is not a multicast IP address, then the verifier node MUST compare the sender's source address with its own local and global IP addresses. If there is a match it starts the other verification steps. Otherwise, it discards the message silently. If the sender's source address is a multicast IP address but the target address is a unicast IP address, then the verifier node MUST compare the target address with its own local and global IP addresses. If there is a match then it MUST process the other verification steps. If there is no match, it should discard the Rafiee & Zhang Expires February 11, 2015 [Page 3] INTERNET DRAFT CGA bis August 11, 2014 message silently. 3. CGA and Challenges in Variable Length Prefix CGA algorithm, by default, uses a 64-bit prefix. The output of this algorithm is a 64-bit IID. This value is the result of hashing function on CGA parameters and taking only 64 bits of the hashing result (digest). To conform CGA with a dynamic prefix length, the number of bits which are taken from the hashing value should be the same size Having a dynamic prefix, as explained in [cga-attack], might lead to the case where the attacker claim the address ownership of other legitimate nodes with different prefix values. This is specially true and feasible when prefixes are longer than 64 bits. In other words, less bits are available for Interface ID. 4. Security Considerations There is no security consideration 5. IANA Considerations There is no IANA consideration 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)," RFC 3972, March 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC7136] Carpenter, B., Jiang, S., "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014. [cga-attack] Rafiee, H., Meinel, C.,"Possible Attack on Cryptographically Generated Addresses (CGA)", http://tools.ietf.org/html/draft-rafiee-6man-cga-attack , Augst 2014 [variableprefix] Carpenter, B., Chown, T, Gont, F., Jiang, S., Petrescu, A., Yourtchenko, A.," Analysis Rafiee & Zhang Expires February 11, 2015 [Page 4] INTERNET DRAFT CGA bis August 11, 2014 of the 64-bit Boundary in IPv6 Addressing", http://tools.ietf.org/html/draft-ietf-6man-why64 , April 2014 Rafiee & Zhang Expires February 11, 2015 [Page 5] INTERNET DRAFT CGA bis August 11, 2014 Authors' Addresses Hosnieh Rafiee HUAWEI TECHNOLOGIES Duesseldorf GmbH Riesstrasse 25, 80992, Munich, Germany Phone: +49 (0)162 204 74 58 Email: hosnieh.rafiee@huawei.com Dacheng Zhang HUAWEI TECHNOLOGIES Q14 huawei campus, Beiqing Rd., Haidian Dist., Beijing, China E-mail: zhangdacheng@huawei.com Rafiee & Zhang Expires February 11, 2015 [Page 6]