One document matched: draft-zhou-6man-cga-hashagil-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-6man-cga-hashagil-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="draft-zhou-6man-mhash-cga-00">Supporting Hash Algorithms
Agility in Cryptographically Generated Addresses (CGAs)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Sujing Zhou" initials="S.Z." role="editor"
surname="Zhou">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>R.R.China</country>
</postal>
<email>zhou.sujing@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christian Huitema" initials="C.H" surname=" Huitema">
<organization>Microsoft</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>huitema@microsoft.com</email>
<uri/>
</address>
</author>
<author fullname="Ruishan Zhang" initials="R.Z" surname="Zhang">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>889 Bibo Rd, Zhangjiang Hi-Tech Park</street>
<city>Shanghai</city>
<code>201203</code>
<country>P.R.China</country>
</postal>
<email>zhang.ruishan@zte.com.cn</email>
</address>
</author>
<author fullname="Zhenhua XIe" initials="Z.X" surname="Xie">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-52871287</phone>
<facsimile>+86-25-52871000</facsimile>
<email>xie.zhenhua@zte.com.cn</email>
</address>
</author>
<date day="5" month="November" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet Area</area>
<workgroup>6man</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides a discussion for solutions supporting hash
algorithms agility in Cryptographically Generated Addresses (CGAs)
defined in RFC 3972.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In this document, a support for multiple hash algorithms without
limiting security parameter or downgrading the security level of CGAs is
provided. The proposed solution follows the idea of encoding the hash
algorithm identity in the CGA addresses to prevent from downgrading
attacks, the detailed description of downgrading attack can be found in
Section 4.1, RFC 4982.</t>
<section title="Terminology ">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="CGAs">
<t/>
<t>Cryptographically Generated Addresses (CGAs) <xref
target="RFC3972"/> are a kind of stateless addresses, which means the
addresses are used when a site is not particularly concerned with the
exact addresses hosts use as long as they are unique and properly
routable. In contrast with other kinds of stateless addresses, CGAs
are mainly used in situations where security is a concern, especially
when address ownership and data integrity are required.</t>
<t>CGAs have been used in Secure Neighbor Discovery (SEND)<xref
target="RFC3971"/>, Mobility in IPv6(MIPv6)<xref target="RFC4866"/>,
Site Multihoming by IPv6 Intermediation (Shim6)<xref
target="RFC5533"/>, and securing DHCPv6 <xref
target="I-D.ietf-dhc-secure-dhcpv6"/>.</t>
<t>CGAs provide address ownership by hashing a public key and other
information included in the accompanying CGA parameters to part of the
IPv6 address (59 bits), and all messages sent by the host with a CGA
go along with a signature calculated using the private key associated
with the public key. A receiver firstly recalculates the hash of the
CGA parameters and compares the result with the CGA, if the they are
equal, the CGA is valid, then the receiver continues to verify the
signature.</t>
</section>
<section title="Security of CGAs ">
<t>The security of a CGA implementation relies on the public key
cryptographic system adopted and the hash implementation. For the
public key cryptographic system, SEND <xref target="RFC3971"/>
recommends using only RSA for compatibility between implementations,
some other protocols may have their own choices by encoding algorithm
identifier in SubjectPublicKeyInfo <xref target="RFC3280"/>. For the
hash implementation, it is a bit more complex, because not only hash
algorithms are concerned, but also the output length of a hash
algorithm is to be considered.</t>
<t>For a perfect hash algorithm, the computation time an attacker
takes to find a collision is 2^(L/2) , the time it takes t o find a
second-preimage is 2^L, where L is the hash length<xref
target="RFC4270"> </xref>. For a practical hash algorithm, the effort
an attacker needs could be less. So in addition to choosing a
cryptographically strong hash algorithm, it is better to keep the hash
length as long as it is originally designed.</t>
<t>But there are some cases that cannot afford to hold the full hash
length, CGA being one of them because the number of bits in an IPv6
address is quite limited (128 bits in total including 64 bits for
subnet network prefix) and a hash value has to be truncated from 160
bits to 59 bits <xref target="RFC3972"/><xref target="RFC4982"/>. A
technique called "hash extension" is proposed to compensate for the
security loss induced by hash value truncation [hash-extension], by
which both the attacker's and defender's efforts to calculate the same
short hash value is increased by the same proportion, but the ratio of
them is still bound by 2^L theoretically, where L is the truncated
hash value length. In the case of CGA defined in <xref
target="RFC3972"/>, L equals 59 and the proportion is 2^(16*SEC),
where SEC is chosen from 0 to 7. Currently, SEC values between 0 and 2
are sufficient for most IPv6 nodes. As computers become faster, higher
SEC values will slowly become useful.</t>
</section>
<section title="Security Challenges in the Future">
<t/>
<t>Crypto-analysis of the hash algorithms has made fast progress since
2004, as shown in <xref target="RFC4270"/>, which promotes <xref
target="RFC4982"/> to enable multiple hash algorithms in CGAs so that
once the current hash algorithm does not satisfy future requirements
,e.g., potential future applications of the CGAs may need a more
cryptographically secure hash algorithm than SHA-1, the transition to
an alternative hash function is as easy as possible.</t>
<t/>
<t>But where to encode the hash identity ? There are two options
considered in <xref target="RFC4982"/> : in a CGA address or in a CGA
parameter. For the first option, there are only two places left to
insert coding of hash algorithm identity, 3 bits of security parameter
SEC and 59 bits of truncated hash value. To occupy SEC bits will make
some SEC values unusable, to occupy bits assigned to hash value will
further weaken the hash security since hash value length is of
essentiality. For the second option, the advantage is that current CGA
address allocation is not affected at all, especially truncated hash
value is not to be weakened and SEC can choose from the whole range
from 0 to 7, but the problem is that this approach is vulnerable to
bidding down attacks or downgrading attacks if no other security
measures are taken.</t>
<t><xref target="RFC4982"/> took the first option and occupied the
same 3 bits SEC is using for hash algorithm identity, that is</t>
<t><figure>
<artwork><![CDATA[ SEC Value | Meaning
-------------------+-------
000 | sec=0 and SHA-1
001 | sec=1 and SHA-1
010 | sec=2 and SHA-1 ]]></artwork>
</figure></t>
<t>And other SEC values have not yet been defined. As shown in<xref
target="I-D.zhou-6man-mhash-cga"/>, reusing SEC will limit both the
security parameter values and available hash algorithms and ultimately
make CGAs less flexible to be used for variant protocols. For example,
as mentioned in <xref target="RFC3972"/> it is suggested to start
using a low sec value and to replace addresses with higher ones only
when denial-of-service attacks based on brute-force search become a
significant problem in some situations, and it is suggested to start
with higher sec values directly in some situations where CGAs are used
as a part of a strong authentication or secrecy mechanism.</t>
<t><xref target="I-D.zhou-6man-mhash-cga"/> took the first option and
occupied 3 bits from the 59 bits assigned to hash value, and proposed
to compensate the security loss by increasing hash extension security
from 2^(16*SEC) to 2^(16*SEC+3) . The only concern to this approach is
that the ratio of attacker's and defender's work to obtain the same
CGA address is decreased from 2^59 to 2^56.</t>
<t>Besides crypto-analysis of hash algorithms, the rapid progress in
faster and cheaper processors, e.g., GPU, is another challenge to the
security of CGAs in the near future. A GPU is effectively a set of 500
or 1000 microprocessors and much faster than a generic processor when
doing highly parallel tasks, which means some calculation performed
years ago about the safety of hashes may be wrong by 2 or 3 orders of
magnitude – in short, hashes should be 10 bits longer than
expected a few years ago. And technology is continue changing along
the path.</t>
<t>The security challenges show both higher SEC values and stronger
hash algorithms are required. For applications flexibility, a wide
range of SEC values are preferred. Because stronger hash algorithms
are also restricted by the theoretical security bound which is a
function of hash length, it is better to have more bits assigned to
hash value in CGAs. Thus the requirements for CGAs in the future may
be: reasonable variant SEC values, as long as possible bits for hash
value in a CGA , reasonable hash algorithm agility, and compatibility
with current CGA implementations.</t>
<t/>
<t/>
</section>
</section>
<!-- -->
<section title="Potential Solutions">
<t>There could be four types of potential solutions for enhancement of
current CGAs, as shown in Figure 2.</t>
<t><figure>
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEC in CGA | SEC in CGA Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HID |[RFC 4982] I | II |
| in |[I-D.zhou-6man-mhash-cga] | *SEC values =0... 255 |
| CGA | | *hash length = 59~60 bits |
| | | *HID max numbers =4~8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HID | III | IV |
| in |*SEC values =0...7 |*SEC values =0...255 |
| CGA |*hash length = 59 bits |*hash length = 62 bits |
|Para-|*HID max numbers =255 |*HID max numbers =255 |
|meter| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>Type I solutions keep security parameter SEC in CGA address, I,e.,
bits 0~2 in the interface identifier (the last 64 bits a in IPv6
address), and let HID, encoding of hash algorithms, occupy bits in the
interface identifier, either reusing SEC bits as in <xref
target="RFC4982"/>, or reclaim some bits from the 59 bits assigned to
hash value as in <xref target="I-D.zhou-6man-mhash-cga"/>, the summary
of the SEC values, hash length, and HID max number can be found in the
previous section.</t>
<t>Type II solutions reclaim SEC bits and assign some or all of the 3
bits to HID, and put SEC in CGA parameters. Thus the length of hash
value in a interface identifier can be 59 bits or 60 bits, the maximum
number of supported hash algorithms can be 4 or 8. SEC then could choose
values from 0 to 255 providing more flexibility.</t>
<t>Type III solutions keep SEC bits in CGA and put HID in CGA
parameters. Thus SEC values are unchanged, the length of hash value in a
interface identifier is still 59 bits, the maximum number of supported
hash algorithms could be 255 far more than what is actually needed.</t>
<t>Type IV solutions reclaim SEC bits and put both SEC and HID in CGA
parameters. Thus the length of hash value in a interface identifier can
be 62 bits, the maximum number of supported hash algorithms could be 255
far more than what is actually needed, SEC then could choose values from
0 to 255 providing more flexibility.</t>
<t/>
<section title="Security Discussions">
<t>According to the security requirements for the future CGAs as
mentioned in the previous section: reasonable variant SEC values, long
bits for hash value in a CGA , reasonable hash algorithm agility, Type
II, III, IV are all preferable to type I solutions.</t>
<t>But as shown in Section 4, <xref target="RFC4982"/>, all other
solutions except type I are vulnerable to downgrading attacks if no
other security measures are taken. Specifically, addresses of type II
and IV are at risks of attacks of using a less value of the SEC field,
addresses of type III and IV are at risks of attacks of using a weaker
hash algorithm. It is arguable which kind of attacks are easier to
implement. If the goal of CGA is to counter against downgrading
attacks using less SEC values, then type III solutions are suitable;
if the goal of CGA is to counter against downgrading attacks using
weaker hash algorithms, then type II solutions are preferable. Type I
solutions are immune to all the above mentioned downgrading
attacks.</t>
<t/>
<t>To defend against downgrading attacks, receivers, who verify the
CGA addresses, may adopt their own policy filter and refuse to trust
CGA addresses if the hash algorithm is deemed to weak, or the SEC
field too short. This offers a protection against attempts to weaken
the security of CGA by presenting insufficient values in parameter
fields for addresses of type II, III and IV. The senders who want to
benefit from CGAs and obtain greater protection SHOULD adopt higher
SEC values and stronger hash algorithms, but whether the effort of a
sender is effective, is actually dependent on the protection level of
policy at the receiver side . If the receiver is so dumb as to accept
any malformed address , there is nothing the sender can do.</t>
<t>Type I solutions are attractive in secure against downgrading
attacks, because SEC values and hash algorithms are hard coded in the
addresses. But type I solutions do not prevent careless senders
themselves from choosing low SEC value or weaker hash algorithm.
Security policy at the receiver side is still necessary.</t>
<t>Using additional security measures, e.g., security policy, besides
the security mechanism in CGAs themselves is reasonable and necessary.
CGAs are only utensils that could be used by any internet protocols,
it is the responsibility of those protocols that should manage the
risk of using CGAs improperly. And those protocols have variant
security requirements, it is impossible for the intrinsic security
embedded in CGAs to fit for all their requirements.</t>
<t/>
</section>
<section title="Compatibility Discussions ">
<t>The solution of <xref target="RFC4982"/> in type I has a
disadvantage that sometime in the future two different implementations
may have different interpretation for the same SEC values, so a long
time is required between the deprecation of the old value and the
reassignment in order to prevent misinterpretation of the value by old
implementations.</t>
<t>While other solutions do not have the problem of misinterpretation,
they do need to consider the compatibility problem with current CGA
implementations. Various compatibility solutions could be taken. For
example, currently undefined SEC=111 in <xref target="RFC4982"/> could
be used to denote that actual security parameter and hash algorithm
identity are included in CGA parameters. For another example, version
information could be added in CGA parameters or in CGA addresses, thus
CGA without version information is looked as conforming to current
implementation.</t>
</section>
</section>
<section title="Conclusions">
<t>According to the above analysis, no solution type is absolutely
better than others considering multiple factors, and any solution type
could be compensated by additional security mechanism since CGA is only
part of a bigger picture, e.g., security policy could be applied. But
considering later flexibility, cryptanalysis progress and computing
capability advancement, current CGA solution (RFC4982) is debatable.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request for IANA now, but may have request
once the final solution is determined.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>See security discussions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.3972.xml'?>
<?rfc include='reference.RFC.4982.xml'?>
<?rfc include='reference.RFC.3280.xml'?>
<?rfc ?>
</references>
<references title="Informative References">
<reference anchor="hash-extension">
<front>
<title>Strengthening Short Hash Values</title>
<author fullname="TUOMAS AURA">
<organization>Microsoft Research, Cambridge, UK</organization>
</author>
<author fullname="MICHAEL ROE">
<organization>Microsoft Research, Cambridge, UK</organization>
</author>
<date/>
</front>
</reference>
<?rfc include='reference.I-D.zhou-6man-mhash-cga'
?>
<?rfc include='reference.RFC.4270.xml'?>
<?rfc include='reference.RFC.4866.xml'?>
<?rfc include='reference.I-D.ietf-dhc-secure-dhcpv6'?>
<?rfc include='reference.RFC.5533.xml'?>
<?rfc include='reference.RFC.3971.xml'?>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:00 |