Internet DRAFT - draft-rafiee-rfc3972-bis
draft-rafiee-rfc3972-bis
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]
