6man S. Zhou, Ed.
Internet-Draft R. Zhang
Intended status: Standards Track Z. Xie
Expires: September 2, 2012 ZTE Corporation
March 1, 2012
Another Support for Multiple Hash Algorithms in Cryptographically
Generated Addresses (CGAs)
draft-zhou-6man-mhash-cga-00
Abstract
This document provides a support for multiple hash algorithms in
Cryptographically Generated Addresses (CGAs) defined in RFC 3972.
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 September 2, 2012.
Copyright Notice
Copyright (c) 2012 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
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.
Zhou, et al. Expires September 2, 2012 [Page 1]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mhash-method Extension . . . . . . . . . . . . . . . . . . . . 3
3. Hash Algorithm Identity Parameter . . . . . . . . . . . . . . . 4
4. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 4
5. CGA Verification Procedure . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhou, et al. Expires September 2, 2012 [Page 2]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
1. Introduction
Cryptographically Generated Addresses (CGAs) defined in [RFC 3972] is
a method of binding a public key to an IPv6 address, with the aim of
providing address ownership in many internet protocols. But RFC3972
only defined a unique hash algorithm, SHA-1, used to hashing a public
key into part of the neitwork IP address. To provide a support for
multiple hash algorishms, a method of reusing the security parameter
bits in the address is secified [RFC 4982] . This method can only
support three hash algorithm at most, and at the same time limiting
security parameter to a few values. In this document, a support for
multiple hash algorithms is provided without limiting security
parameter or downgrading the security level of CGAs.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Mhash-method Extension
To accomodate RFC 4982, an extension field "Mhash-method" is defined.
The format is illustrated in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mhash-method|
+-+-+-+-+-+-+-+
Extension Type: TBA. (16-bit unsigned integer).
Extension Data Length: 1. (16-bit unsigned integer. Length of the
multiple-hash-method field of this option, in octets.)
Mhash-method: 1 octet length field. If Mhash-method equal 0, it
means the method of denoting hash algorithm specified in RFC 4982 is
adopted, if Mhash-method equal 1, it means the method specified in
this document is adopted.
Zhou, et al. Expires September 2, 2012 [Page 3]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
3. Hash Algorithm Identity Parameter
A hash algorithm identity parameter (hid) in CGA is defiend to denote
the hash algorithm adopted when caculating HASH1 and HASH2. The hash
algorithm identity parameter is a three-bit unsigned integer, and it
is encoded in the 3rd-5th bits of the interface identifier. This can
be written as follows:
hid = (interface identifier & 0x1c00000000000000) >> 58
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sec | hid |0 0| Leftmost 56 bits of HASH1 output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. CGA Generation Procedure
Generate a CGA as defined in RFC 3972 except some modification to
steps 2,3,5,6 and 9 as shown in the following:
1. Set the modifier to a random or pseudo-random 128-bit value.
2. Concatenate from left to right the modifier, 9 zero octets, the
encoded public key, and any optional extension fields. Execute
the adopted hash algorithm ( denoted by value of hid) on the
concatenation. Take the 112( or 115 in case sec=7 ) leftmost
bits of the hash value. The result is Hash2.
3. Compare the 16*Sec+3 leftmost bits of Hash2 with zero. If they
are all zero, continue with step 4. Otherwise, increment the
modifier by one and go back to step 2.
4. Set the 8-bit collision count to zero.
5. Concatenate from left to right the final modifier value, the
subnet prefix, the collision count, the encoded public key, and
any optional extension fields. Execute the adopted hash
algorithm on the concatenation. Take the 56 leftmost bits of the
hash value. The result is Hash1.
6. Form an interface identifier from Hash1 by writing the value of
Sec into the three leftmost bits, writing teh value of hid into
the following three bits and by setting bits 6 and 7 (i.e., the
"u" and "g" bits) to zero.
7. Concatenate the 64-bit subnet prefix and the 64-bit interface
identifier to form a 128-bit IPv6 address with the subnet prefix
Zhou, et al. Expires September 2, 2012 [Page 4]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
to the left and interface identifier to the right, as in a
standard IPv6 address .
8. Perform duplicate address detection if required. If an address
collision is detected, increment the collision count by one and
go back to step 5. However, after three collisions, stop and
report the error.
9. Form the CGA Parameters data structure by concatenating from left
to right the final modifier value, the subnet prefix, the final
collision count value, the encoded public key, Mhash-method value
(equal 1 in this case) and any other optional extension fields.
5. CGA Verification Procedure
Veirfy a CGA as defined in RFC 3972 except some modification to steps
3,4,6 and 7 as shown in the following:
1. Check that the collision count in the CGA Parameters data
structure is 0, 1, or 2. The CGA verification fails if the
collision count is out of the valid range.
2. Check that the subnet prefix in the CGA Parameters data structure
is equal to the subnet prefix (i.e., the leftmost 64 bits) of the
address. The CGA verification fails if the prefix values differ.
3. if the Mhash-method value in the Mhash-method extenstion filed is
1, read the hash algorithm identity parameter hid from the 3rd-
5th bits of the 64-bit interface identifier of the address,
execute the hash algorithm denoted by hid on the CGA Parameters
data structure. Take the 56 leftmost bits of the hash value.
The result is Hash1. If the Mhash-method value in the Mhash-
method extenstion filed is 0, do exactly as sepcified in RFC 3972
and RFC4982.
4. Compare Hash1 with the interface identifier (i.e., the rightmost
56 bits) of the address. If the 56-bit values differ, the CGA
verification fails.
5. Read the security parameter Sec from the three leftmost bits of
the 64-bit interface identifier of the address. (Sec is an
unsigned 3-bit integer.)
6. Concatenate from left to right the modifier, 9 zero octets, the
public key, and any extension fields that follow the public key
in the CGA Parameters data structure. Execute the hash algorithm
denoted by hid on the concatenation. Take the 112 (or 115 in
Zhou, et al. Expires September 2, 2012 [Page 5]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
case sec=7) leftmost bits of the SHA-1 hash value. The result is
Hash2.
7. Compare the 16*Sec+3 leftmost bits of Hash2 with zero. If any
one of them is not zero, the CGA verification fails. Otherwise,
the verification succeeds.
6. IANA Considerations
This document defines one new CGA Extension Type [RFC4581] option,
which must be assigned by IANA:
Name: Mhash-method extension type;
Value: TBA.
Description: see Section 2.
The values of Mhash-method are also defined:
Name: Mhash-method extension value;
Value: 0 meaning RFC 4982, 1 meaning this document;
Description: see Section 2.
This document also defines a new parameter (hid) in CGA, the value of
which must be assigned by IANA. It may be assigned as follows:
Name | Value
-------------------+-------
SHA-1 | 000
SHA-244 | 001
SHA-256 | 010
SHA-384 | 011
SHA-512 | 100
TBD | 101
TBD | 110
TBD | 111
7. Security Considerations
The method in this document have the hash algorithm identifier as
part of the interface identifier and ultimatly part of IPv6 address,
downgrading attack can be avoided as analysed in RFC 4982.
Zhou, et al. Expires September 2, 2012 [Page 6]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
WIth 3 bits off the interface identifier used for output of HASH1,
the security level will be downgraded to O(2^56) from O(2^59), but
with the increment by 3 of the check bits in the output of HASH2, the
whole security level is kept the same, i.e.,O( 2^(16*sec+59)).
8. 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.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007.
Authors' Addresses
Sujing Zhou (editor)
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
R.R.China
Email: zhou.sujing@zte.com.cn
Ruishan Zhang
ZTE Corporation
889 Bibo Rd, Zhangjiang Hi-Tech Park
Shanghai 201203
P.R.China
Email: zhang.ruishan@zte.com.cn
Zhou, et al. Expires September 2, 2012 [Page 7]
Internet-Draft draft-zhou-6man-mhash-cga-00 March 2012
Zhenhua XIe
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
P.R.China
Phone: +86-25-52871287
Fax: +86-25-52871000
Email: xie.zhenhua@zte.com.cn
Zhou, et al. Expires September 2, 2012 [Page 8]