[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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
                    <draft-rafiee-rfc3972-bis-00.txt>

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]