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
- CGA Security improvement Hosnieh Rafiee
- Re: CGA Security improvement Roland Bless
- RE: CGA Security improvement Hosnieh Rafiee