CGA Security improvement

Hosnieh Rafiee <hosnieh.rafiee@huawei.com> Fri, 31 July 2015 07:34 UTC

Return-Path: <hosnieh.rafiee@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3ED1B32DA for <ipv6@ietfa.amsl.com>; Fri, 31 Jul 2015 00:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.811
X-Spam-Level:
X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyAQx6ud0U0D for <ipv6@ietfa.amsl.com>; Fri, 31 Jul 2015 00:34:21 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349A11A1ADD for <6man@ietf.org>; Fri, 31 Jul 2015 00:34:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVR95274; Fri, 31 Jul 2015 07:34:18 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 08:33:58 +0100
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: "6man@ietf.org" <6man@ietf.org>
Subject: CGA Security improvement
Thread-Topic: CGA Security improvement
Thread-Index: AdDLY0Jfb2lMlsc0QgS0/pAOeCMitg==
Date: Fri, 31 Jul 2015 07:33:57 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D2C0A@lhreml504-mbs>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.82.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/SJZ-unk84C7SgGQkqU_8-6sh0GU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 07:34:23 -0000

Hi,


I would like to update draft-rafiee-rfc3972-bis-00 draft with the following content. What do you think about it? Any comments or questions? 



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 

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.  CGA key size 

   Since there is no default key size mentioned in CGA specification, as 
   explained in [cga-attack], an attacker might use a very short key 
   size in order to easily play with it and generate a CGA value similar 
   to the victim one, in a timely manner. To prevent this attack, CGA 
   node MUST not use any key sizes that lower than 2048 bits. In future, 
   if there is any attack reported on this key size, CGA node SHOULD use 
   higher key sizes. 

Thanks,
Best,
Hosnieh


[cga-attack] https://tools.ietf.org/html/draft-rafiee-6man-cga-attack-01