< draft-laganier-ipv6-khi-06.txt   draft-laganier-ipv6-khi-07.txt >
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab Internet-Draft Ericsson Research Nomadic Lab
Intended status: Standards Track J. Laganier Intended status: Standards Track J. Laganier
Expires: August 12, 2007 DoCoMo Euro-Labs Expires: August 18, 2007 DoCoMo Euro-Labs
F. Dupont F. Dupont
CELAR CELAR
February 8, 2007 February 14, 2007
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID) (ORCHID)
draft-laganier-ipv6-khi-06 draft-laganier-ipv6-khi-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2007. This Internet-Draft will expire on August 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document introduces Overlay Routable Cryptographic Hash This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID) as a new, experimental class of IPv6-address- Identifiers (ORCHID) as a new, experimental class of IPv6-address-
like identifiers. These identifiers are intended to be used as end- like identifiers. These identifiers are intended to be used as end-
skipping to change at page 6, line 31 skipping to change at page 6, line 31
function to be used for generation of ORCHIDs in this function to be used for generation of ORCHIDs in this
context. These values are allocated out of the the context. These values are allocated out of the the
name space introduced for CGA Type Tags; see RFC 3972 name space introduced for CGA Type Tags; see RFC 3972
and http://www.iana.org/assignments/cga-message-types and http://www.iana.org/assignments/cga-message-types
Hash_function : The one way hash function (i.e. hash function with Hash_function : The one way hash function (i.e. hash function with
pre-image resistance and second pre-image resistance) pre-image resistance and second pre-image resistance)
to be used according to the document defining the to be used according to the document defining the
context usage identified by the Context ID. context usage identified by the Context ID.
For example, the current version of the HIP For example, the current version of the HIP
specification defines SHA-1 [RFC3174] as the hash specification defines SHA1 [RFC3174] as the hash
function to be used to generate ORCHIDs used in the function to be used to generate ORCHIDs used in the
HIP protocol [I-D.ietf-hip-base]. HIP protocol [I-D.ietf-hip-base].
Encode_100( ) : An extraction function which output is obtained by Encode_100( ) : An extraction function which output is obtained by
extracting the middle 100-bit long bitstring from the extracting the middle 100-bit long bitstring from the
argument bitstring. argument bitstring.
Prefix : A constant 28-bit long bitstring value, TBD, assigned Prefix : A constant 28-bit long bitstring value, TBD, assigned
by IANA. by IANA.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
The desire to allow multiple mechanism to share the name space has The desire to allow multiple mechanism to share the name space has
been resolved by including the context identifier in the hash been resolved by including the context identifier in the hash
function input. While this does not allow the mechanism to be function input. While this does not allow the mechanism to be
directly inferred from a ORCHID, it allows one to verify that a given directly inferred from a ORCHID, it allows one to verify that a given
input bitstring and ORCHID belong to a given context, with high input bitstring and ORCHID belong to a given context, with high
probability; but see also Section 6. probability; but see also Section 6.
6. Security Considerations 6. Security Considerations
ORCHIDs are designed to be securely bound to the context identifier ORCHIDs are designed to be securely bound to the Context ID and the
and the bitstring used as the input parameters during their bitstring used as the input parameters during their generation. To
generation. To provide this property, the ORCHID generation provide this property, the ORCHID generation algorithm relies on the
algorithm relies on the second-preimage resistance (a.k.a. one-way) second-preimage resistance (a.k.a. one-way) property of the hash
property of the hash function used in the generation [RFC4270]. To function used in the generation [RFC4270]. To have this property,
have this property, and to avoid collisions, it is important that the and to avoid collisions, it is important that the allocated prefix is
allocated prefix is as short as possible, leaving as many bits as as short as possible, leaving as many bits as possible for the hash
possible for the hash output. output.
All mechanism using ORCHIDs MUST use exactly the same mechanism for For a given Context ID, all mechanisms using ORCHIDs MUST use exactly
generating a ORCHID from the input bitstring. Allowing different the same mechanism for generating a ORCHID from the input bitstring.
mechanisms, without explicitly encoding the mechanism in the ORCHID Allowing different mechanisms, without explicitly encoding the
itself, would allow so called bidding down attacks. That is, if mechanism in the Context ID or the ORCHID itself, would allow so
multiple different hash functions were allowed in constructing called bidding down attacks. That is, if multiple different hash
ORCHIDs in a given shared name space, and if one of the hash functions were allowed in constructing ORCHIDs valid for the same
functions became insecure, that would allow attacks against even Context ID, and if one of the hash functions became insecure, that
those ORCHIDs that had been constructed using the other, still secure would allow attacks against even those ORCHIDs valid for the same
Context ID that had been constructed using the other, still secure
hash functions. hash functions.
Due to the desire to keep the hash output value as long as possible, Due to the desire to keep the hash output value as long as possible,
the present design allows only one method for constructing ORCHIDs the hash function is not encoded in the ORCHID itself, but rather in
from input bitstrings. If other methods (perhaps using more secure the Context ID. Therefore, the present design allows only one method
hash functions) are later needed, they MUST use a different prefix. per given Context ID for constructing ORCHIDs from input bitstrings.
Consequently, the suggested method to react to the hash result If other methods (perhaps using more secure hash functions) are later
becoming too short, due to increased computational power or to the needed, they MUST use a different Context ID. Consequently, the
used hash function becoming insecure due to advances in cryptology, suggested method to react to the hash result becoming too short, due
is to allocate a new prefix and cease to use the present one. to increased computational power or to the used hash function
becoming insecure due to advances in cryptology, is to allocate a new
Context ID and cease to use the present one.
As of today, SHA1 [RFC3174] is considered as satisfying the second- As of today, SHA1 [RFC3174] is considered as satisfying the second-
preimage resistance requirement Hash output of 100 bits is considered preimage resistance requirement. The current version of the HIP
to have a low enough probability of collisions. specification defines SHA1 [RFC3174] as the hash function to be used
to generate ORCHIDs for the Context ID used by the HIP protocol
[I-D.ietf-hip-base].
In order to preserve a low enough probability of collisions (see In order to preserve a low enough probability of collisions (see
Section 4), each method MUST utilize a mechanism that makes sure that Section 4), each method MUST utilize a mechanism that makes sure that
the distinct input bitstrings are either unique or statistically the distinct input bitstrings are either unique or statistically
unique, within that context. There are several possible methods to unique, within that context. There are several possible methods to
ensure that; for example, one can include into the input bitstring a ensure that; for example, one can include into the input bitstring a
globally maintained counter value, a pseudo-random number of globally maintained counter value, a pseudo-random number of
sufficient entropy (minimum 100 bits), or a randomly generated public sufficient entropy (minimum 100 bits), or a randomly generated public
cryptographic key. The Context ID makes sure that input bitstrings cryptographic key. The Context ID makes sure that input bitstrings
from different contexts never overlap. These together make sure that from different contexts never overlap. These together make sure that
the probability of collisions is determined only by the probability the probability of collisions is determined only by the probability
of natural collisions in the hash space and is not increased by a of natural collisions in the hash space and is not increased by a
possibility of colliding input bit strings. possibility of colliding input bitstrings.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a temporary non-routable 28-bit prefix IANA is requested to allocate a temporary non-routable 28-bit prefix
from the IPv6 address space. By default, the prefix will be returned from the IPv6 address space. By default, the prefix will be returned
to IANA in 2027, continued use requiring IETF consensus. As per to IANA in 2027, continued use requiring IETF consensus. As per
[RFC4773], the 28-bit prefix shall be drawn out of the IANA Special [RFC4773], the 28-bit prefix shall be drawn out of the IANA Special
Purpose Address Block, namely 2001:0000::/23, in support of the Purpose Address Block, namely 2001:0000::/23, in support of the
experimental usage described in this document. The allocation will experimental usage described in this document. The allocation will
require updating the IANA IPv6 Special Purpose Address Registry. require updating the IANA IPv6 Special Purpose Address Registry.
 End of changes. 10 change blocks. 
31 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/