One document matched: draft-van-beijnum-multi6-cbhi-00.txt
Internet Draft I. van Beijnum
Document: draft-van-beijnum-multi6-cbhi-00.txt January 2004
Expires: July 2004
Crypto Based Host Identifiers
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This memo specifies a 64-bit crypto-based host identifier that can
be used as an interface identifier in protocols that allow address
agility, such as [ODT]. The cryptographic nature of the host
identifier makes it possible to determine whether a correspondent
is legitimately using said host identifier or not.
The host identifiers can be used as regular interface identifiers
in protocols that don't require an identifier that is separate from
locators, or they can be expanded to 128-bit IPv6 address like
values for use with protocols that do need such an identifier-only
value.
1. Introduction
In many types of interactions across the network it is important to
know the identity of the correspondent. This is especially true in
multihoming and mobility, where a correspondent may change its
address during a session. In [MIPv6], [NOID] and [ODT] it has been
shown to be possible to solve mobility and multihoming without
introducing a long-lived host or stack name identifier. However,
this doesn't mean that having such an identifier would be without
benefits. This document explores the possibility of adding a means
Van Beijnum Expires July 31, 2004 [Page 1]
Internet-Draft Crypto Based Host Identifiers January 2004
to identify a host independent of the full IPv6 address used by the
host and independent of a specific multihoming or mobility
solution.
2. Overview
There are two types of crypto-based host identifiers 64 bit and 80
bit. The 64 bit type consists of 4 control bits, 48 site key bits
and a 12 bit host number:
0 8 16 24 32 40 48 56 63
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| site |C | site (continued) | host |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The 64 bit host identifiers are appropriate in cases where the
subnet bits (bits 48 - 63 in the IPv6 address) are subject to
change, for instance in a host multihoming or mobility situation.
When the subnet bits are fixed, which is likely to be the case with
site multihoming or when no address changes are expected, 80 bit
host identifiers that include the subnet bits are more appropriate,
as these allow significantly more hosts to be grouped together in a
site. The 80 bit host identifier consists of 4 control bits, 44
site key bits, a 16 bit host number and a 16 bit subnet number:
0 8 16 24 32 40 48 56 64 72 79
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| subnet | site |C | site (continued) | host |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The control bits are:
- reserved
- 80 bit identifier (1) or 64 bit identifier (0)
- u/l and g bits as outlined below
3. EUI-64 Compatibility
Generally, a host will create IPv6 addresses for interfaces based
on the interface's EUI-64 as outlined in [RFC 2462]. In order to
avoid overlap from addresses generated by [RFC 3041] and from
regular EUI-64 interface identifiers, for crypto-based host
identifiers the universal/global bit is set to "universal" and the
group bit is set to indicate a group (multicast) address. Note that
the resulting EUI-64 value is only valid for the purposes of
generating IPv6 addresses in accordance with [RFC 2462]. Under no
circumstances may such a value be assigned to an interface for use
as a link address.
Van Beijnum Expires July 31, 2004 [Page 2]
Internet-Draft Crypto Based Host Identifiers January 2004
4. The Site Identifier
The site identifier is created by generating a key pair using a
public key crypto algorithm (to be decided). Then the SHA-1
algorithm is used to calculate a hash over the public key. If 80
bit host identifiers are to be used, the site identifier consists
of the first 44 bits of the SHA-1 hash. If 64 bit host identifiers
are to be used, the site identifier consists of the last 48 bits of
the SHA-1 hash. (The terms "site identifier" and "site key bits"
are used interchangeably.)
All hosts that hold a host identifier must have a set of public key
cryptographic keys. The host's public key is signed using the site
secret key.
Site identifiers, along with the full self-signed public key and
other pertinent information, are registered publicly to avoid and
resolve site identifier collisions. When a newly generated site
identifier collides with an existing one, the new key pair is
discarded and a new one is generated. This is the only required use
of a public registry. All other use of such a registry is optional.
Since it is computationally expensive to generate working keys that
match a specific site identifier, possession of the secret key
provides a "proof of ownership" of a site identifier that is good
enough to fend off denial of service attacks and to provide
authentication with a strength level somewhere between a simple
encrypted password and full-out IPsec. An important feature is
that the site identifier registry doesn't require rooted authority:
any mechanism that makes a full list of site identifiers and public
keys along with serial numbers available to anyone who wants to do
a lookup within a reasonable timeframe after new identifiers have
been generated is sufficient. A small number of repositories that
accept new site identifiers and accompanying material after
checking the signature would work well. Each repository could work
independently but they could exchange new site identifiers for the
sake of completeness. Repositories can then make their contents
available through mirroring and direct querying mechanisms. A good
way to allow direct queries to the site identifier database would
be by publishing a copy of an up to date repository in the DNS.
A fully populated 44 or 48 bit range of values is too large to
store in the DNS without additional hierarchical structure.
However, these ranges will never be fully populated, both because
such a large number of site identifiers isn't necessary and because
at some point, the chance of successive collisions becomes too
large to be able to generate a new site identifier efficiently. A
target for optimum performance would be a population somewhere
between one in a million (approximately 17 million and 260 million
Van Beijnum Expires July 31, 2004 [Page 3]
Internet-Draft Crypto Based Host Identifiers January 2004
site identifiers respectively) and one in a thousand (17 / 260
billion site identifiers). Current practice shows that the DNS can
handle flat spaces with up to several tens of millions entries, so
a modest growth rate (well below Moore's Law) maxing out at around
one to ten billion sites in 2050 shouldn't be a problem.
5. The Challenge/Response Mechanism
When a host wants to authenticate a correspondent using a
crypto-based host identifiers, it issues a challenge to the
correspondent. The layout of the challenge and the way it is
transmitted to the correspondent is to be decided later.
When checking a response, a host may optionally take advantage of
information published in the DNS or through other means. This
allows the host to detect whether it's dealing with the "real"
holder of a site locator rather than an impostor that stumbled on a
key pair that maps to an existing site identifier. It also allows
for retiring a compromised host key: if the published site serial
number is higher than that presented by the correspondent, the host
key is invalid.
6. Turning the Site Identifier into an Address Range
In certain types of multihoming solutions, such as [ODELL96], the
locator and identifier functions of the IP address are separated.
In these cases, the upper layer protocols such as TCP and UDP only
see the identifier. In [ODELL96] the identifier consists of the
lower 64 bits of the IPv6 address, which is compatible with what is
proposed here. However, intra-site connectivity using just the
lower 64 bits of the IPv6 address is problematic. To avoid this
problem, and in order to provide a range of stable addresses a site
may use regardless of its connectivity to the Internet, the site
identifier may be transformed into a site prefix.
The procedure for transforming a 80 bit host identifier into a site
prefix is to take the site identifier bits and concatenate those to
a 4 bit prefix assigned by IANA. The resulting 48 bit value is the
provider independent site prefix. This prefix is combined with a 80
bit host identifier to form a complete IPv6 address.
Example of how a 80 bit host identifier is turned into a 48 bit
site prefix:
Van Beijnum Expires July 31, 2004 [Page 4]
Internet-Draft Crypto Based Host Identifiers January 2004
0 8 16 24 32 40 48 56 64 72 79
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| subnet | site |C | site (continued) | host |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\ \ | |
\ \| |
+--+--+--+--+--+--+--+--+--+--+--+--+
|IA| s i t e i d e n t i f i e r |
+--+--+--+--+--+--+--+--+--+--+--+--+
0 8 16 24 32 40 47
(IA = 4 bit prefix assigned by IANA)
A 64 bit host identifier is turned into a site prefix by
concatenating the site bits with a 12 bit prefix assigned by IANA.
This results in a 60 bit provider independent prefix. To avoid
being limited to a single subnet, the top 4 bits of the host number
are copied to bits 60 - 63 in the IPv6 address. The full 64 bit
host identifier is present in the lower 64 bits to arrive at a full
IPv6 address. This allows for 16 subnets with 256 possible hosts
each.
Example of how a 64 bit host identifier is turned into a 60 bit
site prefix / 64 bit subnet prefix:
0 8 16 24 32 40 48 56 63
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| site |C | site (continued) | host |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\ \ | |
\ \| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| IANA | s i t e i d e n t i f i e r |H |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 8 16 24 32 40 48 56 63
(IANA = 12 bit prefix assigned by IANA)
(H = top 4 bits of the host number)
Use of an EUI-64 that isn't a host identifier as outlined in this
document in combination with one of the above provider independent
prefixes is undefined and not recommended.
7. Operational Overview
If the host identifiers described here are used with ODT, then the
ODT challenge/response interactions are changed as follows. A and B
are hosts communicating using ODT, holding addresses A1, A2 and B1,
B2 respectively. After A sees an address change from B1 to B2 in
Van Beijnum Expires July 31, 2004 [Page 5]
Internet-Draft Crypto Based Host Identifiers January 2004
incoming packets, it issues a challenge to B. Note that unlike with
unmodified ODT there is no need to perform ODT interactions before
a change of address happens, although a highly security conscious
implementation may want to do so anyway.
When A wants to challenge B, it needs to encrypt a nonce using B's
public key. If A doesn't have B's public key yet, it requests B's
public key which must be signed by the site key, along with a copy
of the site public key. A then checks whether the site identifier
bits are indeed the same as the truncated hash derived from B's
site public key, and if so, uses the site public key to check the
signature over B's public key. If this procedure succeeds, A has
B's public key so it can encrypt a nonce and send it to B. B
decrypts the nonce and returns it to A. When A receives back the
nonce, it knows that B holds the matching private key so B's
identity is verified.
8. IANA Considerations
IANA is requested to allocate a /4 and a /12 for crypto-based site
identifier derived provider independent address ranges.
9. Security Considerations
Since the length of the hash over the public key is only 44 or 48
bits, even though finding a key for a known hash is extremely
difficult, there is a significant chance of accidental collisions.
As such, this authentication scheme on its own isn't secure enough
for use with very sensitive applications.
10. Author's Address
Iljitsch van Beijnum
Karel Roosstraat 95
2571 BG The Hague
Netherlands
Phone: +31-70-3103790
Email: iljitsch@muada.com
11. References
[RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", December 1998
[RFC 3041] T. Narten and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
Januari 2001
Van Beijnum Expires July 31, 2004 [Page 6]
Internet-Draft Crypto Based Host Identifiers January 2004
[ODT] I. van Beijnum, "On Demand Tunneling For
Multihoming", work in progress, January 2004
[MIPv6] "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24.txt, work in progress
[NOID] E. Nordmark and T. Li, "Multihoming without IP
Identifiers", draft-nordmark-multi6-noid-00.txt,
work in progress, October 2003
[M6SEC] Nordmark, E., and T. Li, "Threats relating to
IPv6 multihoming solutions",
draft-nordmark-multi6-threats-00.txt, work in
progress, October 2003.
[ODELL96] O'Dell M., "8+8 - An Alternate Addressing
Architecture for IPv6", draft-odell-8+8-00.txt,
work in progress, October 1996
Van Beijnum Expires July 31, 2004 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-21 09:24:18 |