Network Working Group J. Ylitalo
Internet-Draft V. Torvinen
Expires: November 30, 2004 Ericsson Research Nomadiclab
E. Nordmark
Sun Microsystems, Inc.
June 2004
Weak Identifier Multihoming Protocol Framework (WIMP-F)
draft-ylitalo-multi6-wimp-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Weak Identifier Multihoming Protocol Framework (WIMP-F) is a wedge
layer 3.5 framework to be applied with different kind of routable
application layer identifiers (AIDs) and layer 3.5 context
identifiers (CIDs) presented in Group-F. WIMP-F consists of context
establishment and re-addressing exchanges that are protected with
one-way hash chains and a technique called as secret splitting. The
hash chain protects a host from re-direction attacks, but not
Ylitalo, et al. Expires November 30, 2004 [Page 1]
Internet-Draft WIMP-F June 2004
directly from an CID or AID theft. The ownerships can be provided in
variable ways presented in other Multi6 drafts.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. Cryptographic techniques used in WIMP-F . . . . . . . . . . . 5
3.1 One-Way hash chain . . . . . . . . . . . . . . . . . . . . 5
3.2 One-Way hash chain and message authentication . . . . . . 6
3.3 Chained bootstrapping . . . . . . . . . . . . . . . . . . 6
3.4 Secret splitting . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Wedge layer . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Translation between AIDs and Locators . . . . . . . . . . 9
4.3 Host-Pair Context . . . . . . . . . . . . . . . . . . . . 10
4.4 Generating one-way hash chains . . . . . . . . . . . . . . 11
4.5 Context establishment exchange . . . . . . . . . . . . . . 12
4.5.1 State Loss . . . . . . . . . . . . . . . . . . . . . . 14
4.5.2 Identity theft or the initiator has lost its state? . 14
4.5.3 Responder has lost its state . . . . . . . . . . . . . 16
4.6 Re-addressing exchange . . . . . . . . . . . . . . . . . . 18
5. Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 INIT - the context initiator packet . . . . . . . . . . . 20
5.2 CC - the context check packet . . . . . . . . . . . . . . 20
5.3 CCR - the context check reply packet . . . . . . . . . . . 20
5.4 CONF - the context confirm packet . . . . . . . . . . . . 21
5.5 BOOTSTRAP - The bootstrapping packet . . . . . . . . . . . 21
5.6 AC - The address check packet . . . . . . . . . . . . . . 21
5.7 ACR - The address check reply packet . . . . . . . . . . . 22
5.8 SYNC - The re-synchronization packet . . . . . . . . . . . 22
6. Message formats . . . . . . . . . . . . . . . . . . . . . . . 22
6.1 Header format . . . . . . . . . . . . . . . . . . . . . . 22
6.1.1 WIMP-F Controls . . . . . . . . . . . . . . . . . . . 24
6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1 HMAC-INIT . . . . . . . . . . . . . . . . . . . . . . 26
6.2.2 HMAC-CC . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3 HMAC-BOOTSTRAP . . . . . . . . . . . . . . . . . . . . 28
6.2.4 HASHVAL . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.5 ANCHOR . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.6 CIDT . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.7 CHALLENGE . . . . . . . . . . . . . . . . . . . . . . 30
6.2.8 LSET . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.9 KEY . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Packet processing . . . . . . . . . . . . . . . . . . . . . . 33
7.1 Processing outgoing application data . . . . . . . . . . . 33
7.2 Processing incoming application data . . . . . . . . . . . 34
Ylitalo, et al. Expires November 30, 2004 [Page 2]
Internet-Draft WIMP-F June 2004
8. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
9.1 Context establishment exchange . . . . . . . . . . . . . . 38
9.1.1 Man-in-the-Middle attacks . . . . . . . . . . . . . . 38
9.1.2 Denial-of-Service attacks . . . . . . . . . . . . . . 39
9.1.3 Cryptanalysis based on the state loss procedure . . . 39
9.2 Re-addressing exchange . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1 Normative references . . . . . . . . . . . . . . . . . . . . 41
12.2 Informative references . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . 43
Ylitalo, et al. Expires November 30, 2004 [Page 3]
Internet-Draft WIMP-F June 2004
1. Introduction
The reason to name this draft as WIMP-F is that it relies on the same
one-way hash chain procedures as the initial version of WIMP.
However, this draft does not define new application layer identifiers
(AIDs). The WIMP-F exchanges are designed to support any kind of
128-bits AIDs and layer 3.5 context identifiers (CIDs). By default,
the ownership of AIDs can be proved by the reachability test
implemented by the context establishment exchange. A separate
ephemeral CID layer 3.5 namespace can be used to protect host from
CID theft.
WIMP-F offers a context establishment and locator update exchanges
for other Group-F identifiers. It protects hosts from re-direction
attacks by supporting one-way hash chains. Other Group-F protocols
applying WIMP-F are responsible for defining the properties of AIDs
and CIDs
WIMP-F defines a new service at the IP layer rather than a new layer
in the stack. It assumes that AIDs are routable from their nature,
and there is one-to-many binding between the AIDs and the locators.
In other words, a single AID is bound to a IP layer locator set, but
it still has a locator role also itself. In addition, the AID may
also have cryptographical properties. If the AIDs are not
cryptographical from their nature, it may be possible to apply the
same framework also with IPv4 hosts. Therefore, the message
structures are designed to support both IPv6 and IPv4 hosts.
WIMP-F can be used to gradually update a legacy TCP connection to
Multi6 enabled connection depending on the Group-F design.
Furthermore, if WIMP-F protocol finds out that the responding party
has already a state for context identifier -pair, the initiating
party may change its context identifier or prove the identifier
ownership using some strong authentication mechanism, depending on
the type of context identifier.
2. Notational Conventions
- 'I' is an initiator. The party that initiates an exchange is
called an initiator.
- 'R' is a responder.
- Upper Layer Protocol (ULP). A protocol layer immediately above
IP. Examples are transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as OSPF, and
internet or lower-layer protocols being "tunneled" over (i.e.,
encapsulated in) IP such as IPX, AppleTalk, or IP itself.
Ylitalo, et al. Expires November 30, 2004 [Page 4]
Internet-Draft WIMP-F June 2004
- Application Identifier (AID). AID is a 128-bit routable IP
locator which has been selected for communication with a peer to
be used by the upper layer protocol. This is used for
pseudo-header checksum computation and connection identification
in the ULP.
- Context Identifier (CID). CID-pair is used by the wedge layer
to establish and identify the context during context establishment
and address update exchanges. A 128-bit CID may be the same as
the corresponding AID, or they may be separated from each other.
- Context Identifier Tag (CIDT). CIDT together with a
locator-pair are included in every payload packet to identify a
context. E.g. in NOID, the flowid, and in HIP, the SPI value.
CIDT is conceptually distinguished from the any specific field, so
that it can be used with any payload extension header.
- 'Ls' is a locator set consisting of L1, ... Ln.
- 'Hk' is k:th hash value in the hash chain. 'H0' is the first
revealed value, i.e. the "anchor" of the hash chain. Note that
the parameter k defines the revealing order, not the computation
order.
3. Cryptographic techniques used in WIMP-F
3.1 One-Way hash chain
One-Way hash chain [7] is cryptographically generated list of data
entities with some interesting characteristics. It is practically
impossible to calculate or otherwise figure out the next value in the
chain even when you know the previous value. However, it is very
easy to verify whether some given value is the next value or not.
The chain is created by recursively computing a hash function over a
result of the same function. The initial argument for the first hash
value computation is typically a large random number. The last
generated value of the chain is called as the "anchor" or "root"
value. The hash values are revealed in the reverse order starting
from the anchor value.
Hn = Hash(random number)
Hn-1 = Hash(Hn)
...
H0 = anchor = Hash(H1)
CHAIN: H0,..,Hn
Ylitalo, et al. Expires November 30, 2004 [Page 5]
Internet-Draft WIMP-F June 2004
This technique is usually based on an assumption that only an
authentic end-point knows the correct successor values of the chain.
In the bootstrapping process, the end-point computes a new hash chain
and reveals the anchor value of the chain to its peer. It is
important to notice that each hash chain MUST be used only once.
3.2 One-Way hash chain and message authentication
Hashed Message Authentication Codes [2] are typically used to
authenticate messages with a symmetric key. This requires,
naturally, that all communicating peers share a secret.
One-Way hash chain values can be used as keys in the delayed message
authentication (see TESLA [6]). This is different from the shared
secret scheme, because anybody who is able to receive the subsequent
messages is able to verify that the messages belong together. The
one-way hash chain value (key) used in the message authentication is
not revealed before the next message. In other words, the peer is
able verify the message only after it has received the next message.
It is good to notice that a host must receive a confirmation message
before sending the next message to avoid delay attacks. This
procedure can be used to verify that all subsequent messages come
from the same entity than the first message.
A Man-in-the-Middle (MitM) attacker is not able to (unnoticeably)
modify the messages after the first message in the exchange.
However, an attacker may spoof the first message and use its own hash
chain. The protocol is based on opportunistic principle where the
peers trust that the initial message comes from the authentic host.
A -> B: Msg1(A), HMAC(H1(A), Msg1(A))
A <- B: Msg1(B), HMAC(H1(B), Msg1(B))
A -> B: Msg2(A), H1(A), HMAC(H2(A), Msg2(A))
A <- B: Msg2(B), H1(B), HMAC(H2(B), Msg2(B))
...
A -> B: Msgn(A), Hn-1(A), HMAC(Hn(A), Msgn(A))
A <- B: Msgn(B), Hn-1(A), HMAC(Hn(B), Msgn(B))
A -> B: Hn(A)
A <- B: Hn(B)
3.3 Chained bootstrapping
In the basic model, each one-way hash chain is an independent entity.
This is not a problem if the anchor of the chain can be
authenticated, and if the hash chain is known to be long enough to
have values to every message in the communication session. However,
it is possible to use short hash chains to avoid extra computation.
Ylitalo, et al. Expires November 30, 2004 [Page 6]
Internet-Draft WIMP-F June 2004
Basically, the bootstrapping message can be authenticated using
public keys. In the WIMP-F approach, the peers do not authenticate
the bootstrapping message with a signature, but they rely on the
delayed message authentication. Two independently created one-way
hash chains can be linked together with HMAC computation. The last
value of the first one-way hash chain is used to authenticate the
first value of the second chain:
...
A -> B: Msgn, H0new, Hn-1, HMAC(Hn, Msgn || H0new)
A <- B: (conf)
A -> B: Msgn+1, Hn, HMAC(H1new, Msgn+1)
A <- B: (conf)
A -> B: Msgn+2, H1new, HMAC(H2new, Msgn+2)
...
3.4 Secret splitting
In secret splitting [4][5], a secret is divided into several pieces.
Any piece alone does not give enough information for an attacker to
create the original secret. The only way to create the secret is to
posses all the pieces. The splitting is done by generating
random-bit strings, the same length as the original secret. The key
splitting and secret reconstruction is done in the following way:
Constructing key pieces:
K_1 = nonce1
...
K_k-1 = noncek-1
K_k = SECRET XOR K_1 ... XOR K_k-1
Combining the secret:
SECRET = K_1 XOR ... XOR K_k
Secret splitting is useful technique for storing secrets in two
physical places, or for sending a secret to the other end-point using
two or more parallel communication paths.
4. Protocol overview
The framework consists of AIDs, CIDs, CIDTs, and IP layer locators.
Each of them having a special role from the conceptual point of view.
In addition, the framework consists of mechanisms and policies. The
policies, like address selection policy, are out of this draft scope.
The mechanism are used to establish a context and prove the ownership
Ylitalo, et al. Expires November 30, 2004 [Page 7]
Internet-Draft WIMP-F June 2004
of the AID and the context. If AIDs are also used for wedge layer
CIDs, there is no reason to separate these two mechanisms from each
other, and AID ownership can be also used to prove the context
ownership.
WIMP-F supports, by default, locators without any cryptographical
properties. The weak ownership of routable AID is provided by the
implicit reachability during the context establishment. Otherwise,
this draft leaves open the security properties of the routable AIDs
and other mechanisms used to prove the ownership of the AID. It is
good to notice that proving the ownership of AID is an essential
mechanism in the final stand-alone Multi6 solution. However,
routable AIDs may have ephemeral suffixes making the guessing of AIDs
difficult for an attacker. However, in some cases it is not possible
to have such a randomness. The ownership of an AID could be e.g.
based on reverse DNS or public key based cryptography.
The IP layer locators are included in the address fields in the IP
packet headers. Further, each wedge 3.5 layer implementation must
establish a state, i.e. a context, for AID-locator bindings. The
context must be identified with some context identifier (CID) during
context establishment exchange. However, to avoid overhead in packet
sizes, it is possible to compress the CID and include a smaller CID
tag (CIDT) in every payload packet. CIDT is used together with a
locator-pair, in the IP header, to identify a context at the other
end-point.
The WIMP-F context establishment exchange is based on an
opportunistic principle. That is, a host does not care who its peer
is, as long as the peer is the same during the communication context
lifetime. The trust between the peers is established using one-way
hash chains during the initial exchange. The context owner is the
owner of the hash chain. Basically, the CID is just an index that
refers to a correct context. However, if an attacker is able to
guess or otherwise figure out the initiator's CID, the host becomes
vulnerable for context identifier theft. That is, an attacker tries
to establish a state using the identifier of the initiator. However,
it is possible to use ephemeral or cryptographically generated AIDs
as CIDs. In the latter case, a public key signature field must be
added (TBD) to the WIMP-F packet structures. In this case, the
responder should verify the ownership of the AID only after an AID
collision happens. Ephemeral port numbers helps to mitigate AID
ownership problem. However, when AIDs are used for CIDs, such an
extra randomness will disappear.
To protect from redirection attacks the presented protocol relies on
the ability to verify that the entity requesting redirection indeed
holds the successor values of a hash chain and is able to combine a
Ylitalo, et al. Expires November 30, 2004 [Page 8]
Internet-Draft WIMP-F June 2004
divided secret that is sent via parallel paths. WIMP-F offers
context establishment and re-addressing exchanges. The exchanges are
based on UDP, by default. The former exchange establishes a state
for both communication end-points. The re-addressing exchange is
used to implement reachability test and to update the locators
belonging to the communicating parties.
4.1 Wedge layer
+-----------------------------------+
| Transport Protocols |
+-----------------------------------+
| AH | ESP | Frag/reass | Dest opts |
+-----------------------------------+
| Wedge layer |
+-----------------------------------+
| IP |
------------------------------------+
Figure 1: Protocol stack
The proposal uses a wedge layer between IP and the ULPs as shown in
Figure 1, in order to provide ULP independence. Conceptually the
wedge layer behaves as if it is an extension header, which would be
ordered immediately after any hop-by-hop options in the packet.
Layering AH and ESP above the wedge layer means that IPsec can be
made to be unaware of locator changes the same way that transport
protocols can be unaware. Thus the IPsec security associations
remain stable even though the locators are changing. Layering the
fragmentation header above the wedge makes reassembly robust in the
case that there is broken multi-path routing which results in using
different paths, hence potentially different source locators, for
different fragments.
4.2 Translation between AIDs and Locators
Applications and upper layer protocols use AIDs which the wedge layer
will map to/from different locators. The wedge layer maintains
state, called host-pair context, in order to perform this mapping.
The mapping is performed consistently at the sender and the receiver,
thus from the perspective of the upper layer protocols packets appear
to be sent using AIDs from end to end, even though the packets travel
through the network containing locators in the IP address fields, and
even though those locators may be even rewritten in flight.
Ylitalo, et al. Expires November 30, 2004 [Page 9]
Internet-Draft WIMP-F June 2004
+--------------------+ +--------------------+
| Initiator | | Responder |
| | | |
| ULP | | ULP |
| | src AID(I) | | ^ |
| | dst AID(R) | | | src AID(I) |
| v | | | dst AID(R) |
| WEDGE | | WEDGE |
| | src L1(I) | | ^ |
| | dst L1(R) | | | src L1(I) |
| v | | | dst L1(R) |
| IP | | IP |
+--------------------+ +--------------------+
| ^
+- cloud with some routers ----+
Figure 2: Mapping identifiers to locators.
The result of this consistent mapping is that there is no impact on
the ULPs. In particular, there is no impact on pseudo-header
checksums and connection identification.
4.3 Host-Pair Context
The context establishment exchange establishes a state for both
communication end-points. The initiator creates a host-pair context
based on IDs and the locator set. The responder establishes a state
after receiving the second message from the initiator.
The context contains the following information:
- Context identifiers.
- Locator and locator status (e.g. if locator has been verified,
and which locators are preferred for communication)
- Hash chain information (e.g. parameters needed in the
construction of hash chains, last used local chains values, and
last known peer chain values)
Every IP packet must contain information about the related host-pair
context to find the the right one for the received packets.
Basically, it is possible to add an extra extension header to each
packet, containing a context identifier. This results into extra
overhead in the payload packets. On the other hand, a Multi6
protocol may include the context identifier into the IPv6 header
using, e.g., flowid field (NOID), or SPI value (HIP). Each Multi6
protocol defines own mechanism to map packets to Multi6 context.
Ylitalo, et al. Expires November 30, 2004 [Page 10]
Internet-Draft WIMP-F June 2004
Thus, WIMP-F context establishment exchange supports variable size
CIDTs.
4.4 Generating one-way hash chains
The hash chains are needed by the initiator and the responder during
the context establishment and re-addressing exchange. In addition,
the initiator bootstraps a new hash chain during every re-addressing
exchange.
WIMP-F sets the following requirements for the hash chains
generation:
- Each hash chain MUST be bound to end-point identifiers, i.e.,
CID(I) and CID(R).
- Each hash chain MUST be bound to a local secret. Using the
local secret the responder does not need to establish a state
during the first round-trip in the context establishment exchange.
In addition, the local secret, stored in a persistent memory
system, solves the state loss problem. The responder SHOULD reuse
the same local secret with multiple initiators to avoid
establishing a state during the first round-trip.
- Each hash chain MUST be bound to a random string, i.e., a
challenge. The challenge makes each of the hash chains
statistically unique and protects the hosts from attackers that
try to find out hash chain values using spoofed identifiers. The
challenge is initially generated by the host that constructs the
related hash chain.
Initiator:
secret(I/R) = secret random number generated by I/R
challenge(I/R) = public random number generate by I/R
Hk(I/R) = hash chain value
ID(I/R) = end-point identifier
Hn(I) = SHA1(secret(I) || CID(I) || CID(R) || challenge(I))
...
H1(I) = SHA1(H2(I))
H0(I) = SHA1(H1(I))
Responder:
Hn(R) = SHA1(secret(R) || CID(R) || CID(I) || challenge(R))
...
H1(R) = SHA1(H2(R))
Ylitalo, et al. Expires November 30, 2004 [Page 11]
Internet-Draft WIMP-F June 2004
H0(R) = SHA1(H1(R))
The default length of both of the hash chains should be n=10.
Theoretically speaking, the minimum length of the hash chain is four
(4) hash values. This will last for one context establishment
exchange, and one re-addressing exchange for both directions. The
re-addressing exchange includes a bootstrapping procedure where a new
hash chain is created for the initiator. However, each unsuccessful
re-addressing exchange attempt will require one more hash chain
value. Failures in re-addressing exchange may be due to connection
loss in some of the locators, or an active attack. A host should
bootstrap a new hash chain at latest when it has only two hash values
left.
4.5 Context establishment exchange
The context establishment exchange bootstraps hash chains and creates
a state between two end-points. The protocol uses delayed
authentication procedure (see Section 3.2). The responder remains
stateless during the first round-trip. At the end of the exchange
both parties have a uniquely identifiable host-pair context
containing the peer's anchor value.
Initiator Responder
Construct hash chain.
Define CIDs and CIDT(I).
INIT: CIDs, challenge(I), [challenge_old(R), Hn_old(R)],
HMAC_INIT{H0(I), (CIDs || challenge(I) || CIDT(I) || Ls(I))}
-------------------------->
No host-pair context found.
Generate challenge(R).
Construct temporary hash chain.
CC: CIDs, HMAC_INIT, challenge(R), H0(R), Ls(R),
HMAC_CC{H1(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))}
<-------------------------
verify HMAC_INIT remain stateless
CCR: CIDs, HMAC_INIT, challenge(R), H0(R), challenge(I),
HMAC_CC, Ls(I), CIDT(I), H0(I)
-------------------------->
Reconstruct the hash chain.
Verify HMAC_INIT and HMAC_CC.
Define CIDT(R).
CONF: CIDs, H1(R), CIDT(R)
<--------------------------
Ylitalo, et al. Expires November 30, 2004 [Page 12]
Internet-Draft WIMP-F June 2004
verify HMAC_CC
WIMP-F can be used with routable AIDs without cryptographical
properties, supporting separate ephemeral context identifier
namespace. In such a case, the context establishment is based on
opportunistic principle, and each host selects its context identifier
during the exchange. INIT contains Initiator's CID, but Responder's
CID is zero. Responder includes its CID in CC message.
The initiator triggers the exchange by sending a context
initialization message, INIT, to the responder. The INIT message
contains the CIDs, a challenge of the initiator and a HMAC.
Optionally, it contains also an old challenge and the last revealed
hash chain value of the responder (discussed later in Section 4.5.3).
The HMAC_INIT, having an anchor value as a key, is computed over the
CIDs, the context identifier, the challenge and the locator set of
the initiator. The context identifier and the locator set are sent
later in the context check reply message (CCR). The optional values
related to responder's old hash chain are not included into the
HMAC_INIT computation.
Once the responder receives the INIT message, it must check whether
it has already a host-pair context for the CID -pair. If a host-pair
context is found, the responder should assume that the initiator has
lost its state (discussed later in Section 4.5.2). If the context is
not found, but the INIT message contains responder's old challenge
and old hash chain value, the responder should assume it has lost its
state (discussed later in Section 4.5.3). In a typical case, when
the context is not found, and the INIT message does not contains any
optional values, the responder must continue the normal context
establishment exchange.
The responder must not establish a state after receiving the INIT,
because it cannot verify the origin of the message. In order to
remain stateless, the responder generates a fresh challenge and
computes a temporary hash chain, as presented in Section 4.4. The
context check (CC) message contains the CIDs, the received HMAC_INIT,
the responder's challenge, the anchor value, and the locator set.
The message is protected with the second value, H1(R), of responder's
hash chain. The initiator should make reachability test for every
received locator, in the Ls(R), before using it. (discussed later in
Section 4.6).
The initiator replies to the CC message with a context check reply
(CCR) message. The initiator proves that it was reachable at the
specific location by including the HMAC_CC into the message. Using
the responder's challenge and anchor value in the CCR message, the
Ylitalo, et al. Expires November 30, 2004 [Page 13]
Internet-Draft WIMP-F June 2004
responder can reconstruct the hash chain. The CCR message contains
the required information to establish a state and verify the
HMAC_INIT and HMAC_CC. The anchor value, H0(I), binds also the INIT
and CCR messages together. The responder should make a reachability
test for every received locator, in the Ls(I), before using it
(discussed later in Section 4.6).
The responder must drop a CCR packet with an ID pair that already has
a host pair-context. If the context is not found, the responder
reconstructs a hash chain and verifies the HMAC_CC and HMAC_INIT (in
this order). If the HMACs were valid, the responder creates a host
pair context using the CIDs. It also selects a context identifier,
CIDT(R), to be used in the payload packets. Finally, the responder
replies with a context confirmation message (CONF) revealing the
second hash value, H1(R).
The initiator verifies the HMAC_CC using the hash chain value
received in the CONF message, and finalizes its state.
4.5.1 State Loss
The context establishment exchange has been designed in the way that
it can be reused for secure re-synchronization. If a host receives a
valid SYNC message, it should start a new handshake with the INIT
message. The following scenarios describe the main use cases that
are covered by the design:
- The initiator does not have a host-pair context, but the
responder already has one for the CIDs. Either some host (e.g.
an attacker) is already using the the initiator's identifier,
ID(I), or the initiator has earlier lost its state.
- The initiator has a host-pair context, but the responder has
lost its state.
4.5.2 Identity theft or the initiator has lost its state?
If an initiator reboots or times out, it has lost its host-pair
context. The host does not have any prior state and sends INIT (see
Figure 10). If the responder finds out an active host-pair context
corresponding the CIDs, it compares the received challenge(I) with
the old challenge'(I) in the existing context. If the received
challenge(I) is different than the old one, it replies with the SYNC
message containing the initiator's old challenge'(I) and the latest
revealed hash chain value Hk'(I). If the received challenge(I) value
is the same with the old value, the responder replies with CC
message.
Ylitalo, et al. Expires November 30, 2004 [Page 14]
Internet-Draft WIMP-F June 2004
Once the initiator receives SYNC, it reconstructs the old hash chain
using the challenge'(I) and verifies that the Hk'(I) is a valid value
of that hash chain. If the verification fails the initiator MUST
drop the packet. Either 1) the packet was sent by an attacker or 2)
some other host is using the same ID(I). To protect from the former
attack, the initiator SHOULD wait for a while to receive a valid CC
or SYNC packet. Finally, if it does not receive a valid reply, it is
possible that an attacker has established a host-pair context with
the responder using the initiator's identifier (an identity theft).
The initiator has different alternatives to continue the exchange,
depending on the Group-F design. If possible, the initiator SHOULD
change its (ephemeral) CID and restart the exchange. If the
initiator is using a cryptographical identifier (e.g. HIT), it may
prove the ownership with signature included into the WIMP-F packet
(TBD) or start a public key based exchange (e.g. HIP base exchange),
using the same ID(I), to prove to the responder that it is the
authentic owner of the identifier.
However, if the Hk'(I), received in SYNC, was a valid hash chain
value, the initiator has probably lost its state. It SHOULD restart
the context establishment exchange by sending a new INIT message,
protected with a successor hash chain value, Hk+1'(I).
Once the responder receives the INIT message and challenge'(I)
matches with the one in the existing host-pair context, it replies
with CC. The message contains the old last revealed Hn(R), and the
corresponding challenge(R). The HMAC_RR is protected with the
successor value Hn+1(R).
The responder must drop the CCR message if the Hk+1'(I) verification
fails. If Hk+1(I) is valid hash chain value the responder replies
with CONF message, and reveals its successor hash chain value
Hn+1(R).
Initiator: Responder:
Latest revealed value=Hk'(I) Latest revealed value=Hn(R).
before state loss.
Send fresh INIT message
INIT: CIDs, challenge(I),
HMAC_INIT{H0(I), (CIDs || CIDT(I) || challenge(I) || Ls(I))}
-------------------------->
Host-pair context found.
No match with challenge'(I).
Ylitalo, et al. Expires November 30, 2004 [Page 15]
Internet-Draft WIMP-F June 2004
SYNC: CIDs, challenge'(I), Hk'(I)
<-------------------------
Reconstruct old hash chain
using challenge'(I).
Verify Hk'(I).
Restart exchange.
INIT: CIDs, challenge'(I),
HMAC_INIT{Hk+1'(I), (CIDs || CIDT(I) || challenge'(I) || Ls(I))}
-------------------------->
Host-pair context found.
Match with challenge'(I).
CC: CIDs, HMAC_INIT, challenge(R), Hn(R), Ls(R),
HMAC_CC{Hn+1(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))}
<-------------------------
CCR: CIDs, CIDT(I), Hk+1'(I), challenge'(I), Hn(R),
challenge(R), HMAC_INIT, HMAC_CC, Ls(I)
-------------------------->
verify Hk+1'(I)
verify HMAC_INIT and HMAC_CC
update host-pair context
CONF: CIDs, Hn+1(R), CIDT(R)
<--------------------------
verify HMAC_CC
update host-pair context
Figure 10: Initiator has lost its state
4.5.3 Responder has lost its state
If a system receives an IP packet that does not match with any
host-pair context, the host has probably lost its state. The host
replies with SYNC message containing the context identifier that was
received in the IP packet (see Figure 11). Every IP packet must not
trigger a new SYNC message. The SYNC reply frequency must be rate
limited.
Once a host receives a SYNC message containing only a context
identifier, it should try to find a corresponding host-pair context.
If a host-pair context is found the host should send an INIT message
to verify whether the peer has lost its state. The initiator
includes the last revealed hash chain value, Hn(R), and corresponding
Ylitalo, et al. Expires November 30, 2004 [Page 16]
Internet-Draft WIMP-F June 2004
challenge(R) of the responder to the message. The initiator should
not generate new hash chain for itself, but use the successor value,
Hk+1(I), of the existing hash chain to protect the INIT message.
If the responder has a host-pair context for the CIDs, the SYNC
message was sent by an attacker, and the responder must drop the INIT
message containing the old hash chain and challenge values. If the
responder does not have a host-pair context for the CIDs, it should
reconstruct the old hash chain. The responder must verify that the
received hash chain value, Hn(R), is a valid member of the chain. If
the verification fails the responder must drop the INIT message. If
the Hn(R) is valid value, the responder includes the successor value,
Hn+1(R), into CC message, to prove that it has really lost its state.
The rest of the exchange is identical with the normal exchange, but
the responder must reveal the successor value, Hn+2(R), in the CONF
message.
Initiator: Responder:
Latest revealed value=Hk(I). Latest revealed value=Hn(R)
before state loss.
IP packet including CIDT(I)
-------------------------->
No host-pair context found
SYNC: CIDT(I)
<-------------------------
Find host-pair context.
Start exchange.
INIT: CIDs, challenge(R), Hn(R),
HMAC_INIT{Hk+1(I), (CIDs || CIDT(I) || challenge(I) || Ls(I))}
-------------------------->
No host-pair context found.
Construct old hash chain
using challenge(R).
Verify Hn(R).
CC: CIDs, HMAC_INIT, challenge(R), Hn+1(R), Ls(R),
HMAC_CC{Hn+2(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))}
<-------------------------
verify Hn+1(R) remain stateless
CCR: CIDs, CIDT(I), Hk+1(I), challenge(I), Hn+1(R), challenge(R),
HMAC_INIT, HMAC_CC, Ls(I)
-------------------------->
reconstruct the hash chain
verify HMAC_INIT and HMAC_CC
Ylitalo, et al. Expires November 30, 2004 [Page 17]
Internet-Draft WIMP-F June 2004
select CIDT(R)
CONF: CIDs, Hn+2(R), CIDT(R)
<--------------------------
verify HMAC_CC
update host-pair context
Figure 11: Responder has lost its state
4.6 Re-addressing exchange
Once the state has been completed, both hosts have a host-pair
context. As a result, each host knows a locator set of its peer. It
is good to notice that the responder may be multi-homed, even the
initiator does not initially know all of the responder's locators.
The hosts use re-addressing exchange to dynamically update their
locator sets and to bootstrap hash chains.
The initiating party of the context establishment exchange was called
the initiator. Once the host-pair contexts are established, this
initial distinction is lost. Thus, the sender of the BOOTSTRAP
message is called the initiator of the re-addressing exchange.
Initiator Responder
construct new hash chain
BOOTSTRAP: CIDs, Ls(I), Hn(I), H0_new(I), challenge(I),
HMAC{Hn+1(I),(CIDs || Ls(I) || H0_new(I) || challenge(I))}
-------------------------->
Verify H1(I).
Generate a divided secret of Hk(R).
Send AC per locator to be verified.
AC1: CIDs, Key_count, Key_mask, key_piece, challenge(I)
... <-------------------------
ACn <-------------------------
combine the key pieces
verify the combined key
ACR: CIDs, Key_combined, Key_mask, Hn+1(I)
-------------------------->
verify the combined key Hk(R)
verify HMAC
The re-addressing exchange is a three-way handshake. The BOOTSTRAP
Ylitalo, et al. Expires November 30, 2004 [Page 18]
Internet-Draft WIMP-F June 2004
message has two purposes. First, it informs the responder about the
currently active locator set. Second, it bootstraps a new hash
chain.
Once the responder receives a BOOTSTRAP message, it verifies that the
hash chain value, Hn(I), belongs to the initiator. In addition, the
responder stores the initiator's new anchor value, H0_new(I), into
the host-pair context. (Note: a host may verify locators after the
context establishment exchange by directly sending AC messages to the
peer).
The responder divides its next unused hash chain value, Hk(R), into
pieces using the secret splitting technique (See Section 3.4). The
responder MAY verify the locators in the locator set on demand basis
or all at once. In the latter case, the hash chain value is divided
into as many parts as the were locators in the received locator set.
The responder defines a key mask for each of the key pieces (see
Section 6.2.9). The key mask will later allow the responder to check
if all pieces reached the initiator. It is possible that the
initiator is not reachable via all of the locators in the locator
set.
The responder sends one address check message (AC) per locator that
it wants to verify. Each AC message contains one piece of the
divided Hk(R). The initiator should wait a while (TBD) for the
upcoming AC messages. The key count in every AC packet defines the
total amount of pieces, sent by the responder.
If the initiator receives all the pieces of the hash chain value, it
should verify that the combined pieces form a successor value of the
responder's hash chain. Otherwise, the initiator MAY stop the
re-addressing exchange. The initiator makes an OR-operation with all
of the received key masks and includes the result of the operation
with the combined key to the address check reply message (ACR). The
ACR message includes also hash chain value, Hn+1(I) that was used to
protect the HMAC.
The responder identifies the locators which were reachable, using the
combined key and the key mask. The responder authenticates also the
BOOTSTRAP message with hash chain value, Hn+1. Finally, the
responder marks the verified locators valid in the host-pair context.
5. Packets
There are eight basic WIMP-F packets. Four are for the context
establishment exchange, and three are for re-addressing, and one is
for re-synchronization.
Ylitalo, et al. Expires November 30, 2004 [Page 19]
Internet-Draft WIMP-F June 2004
Packets consist of the fixed header as described in Section 6.1,
followed by parameters. The parameter part, in turn, consists of
zero or more TLV coded parameters.
Packet representation uses the following operations:
() parameter
[] optional parameter
An upper layer payload MAY follow the WIMP-F header. The payload
proto field in the header indicates if there is additional data
following the WIMP-F header.
5.1 INIT - the context initiator packet
The WIMP-F header values for the INIT packet:
Header:
Packet Type = 1
SRC CID = Initiator's CID
DST CID = Responder's CID
IP( WIMP-F (CHALLENGE(I), HMAC-INIT, [CHALLENGE(R), HASVAL(R)]))
Valid control bits: P
5.2 CC - the context check packet
The WIMP-F header values for the CC packet:
Header:
Packet Type = 2
SRC CID = Responder's CID
DST CID = Initiator's CID
IP ( WIMP-F (CHALLENGE(R), HASVAL(R), LSET(R), HMAC-INIT, HMAC-CC ))
Valid control bits: P
The CIDs MUST be the same as received in INIT.
The responder copies the HMAC-INIT TLV from the INIT message to the
CC message.
5.3 CCR - the context check reply packet
The WIMP-F header values for the CCR packet:
Ylitalo, et al. Expires November 30, 2004 [Page 20]
Internet-Draft WIMP-F June 2004
Header:
Type = 3
SRC CID = Initiator's CID
DST CID = Responder's CID
IP ( WIMP-F ( HASHVAL(I), HASHVAL(R), CIDT(I), CHALLENGE(I), CHALLENGE(R),
LSET(I), HMAC-INIT, HMAC-CC))
Valid control bits: P
The CIDs used MUST match the ones used in the INIT and CC messages.
The Initiator copies the HMAC-INIT, and HMAC-CC TLVs from the CC
message to the CCR message.
5.4 CONF - the context confirm packet
The WIMP-F header values for the CONF packet:
Header:
Packet Type = 4
SRC CID = Responder's CID
DST CID = Initiator's CID
IP ( WIMP-F ( HASHVAL(R), CIDT(R) ))
Valid control bits: P
The CIDs used MUST match the ones used in the CCR message.
5.5 BOOTSTRAP - The bootstrapping packet
The WIMP-F header values for the BOOTSTRAP packet:
Header:
Packet Type = 10
SRC CID = Initiator's CID
DST CID = Responder's CID
IP ( WIMP-F ( LSET(I), HASHVAL(I), ANCHOR(I), CHALLENGE(I), HMAC-BOOTSTRAP ))
Valid control bits: P
5.6 AC - The address check packet
The WIMP-F header values for the AC packet:
Ylitalo, et al. Expires November 30, 2004 [Page 21]
Internet-Draft WIMP-F June 2004
Header:
Packet Type = 11
SRC CID = Responder's CID
DST CID = Initiator's CID
IP ( WIMP-F ( KEY(R), CHALLENGE(I) ))
Valid control bits: P
The responder copies the CHALLENGE(I) from the BOOTSTRAP message to
the AC message(s)
5.7 ACR - The address check reply packet
The WIMP-F header values for the AC packet:
Header:
Packet Type = 20
SRC CID = Initiator's CID
DST CID = Responder's CID
IP ( WIMP-F ( KEY(I), HASHVAL(I) ))
Valid control bits: P
The KEY TLV is constructed of the received key pieces and their key
masks.
5.8 SYNC - The re-synchronization packet
The WIMP-F header values for the SYNC packet:
Header:
Packet Type = 12
SRC CID = Initiator's CID
DST CID = Responder's CID
IP ( WIMP-F ( CIDT(I), [CHALLENGE(I), HASHVAL(I)] ))
Valid control bits: -
6. Message formats
6.1 Header format
All WIMP-F packets start with a fixed header.
Ylitalo, et al. Expires November 30, 2004 [Page 22]
Internet-Draft WIMP-F June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | Type | VER. | RES. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Controls | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Identifier (CID) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Identifier (CID) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ WIMP-F Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WIMP-F header is carried in UDP payload followed by a next header
that is defined in Next Header field. If no next headers follow, the
decimal 59, IPPROTO_NONE, the IPV6 no next header value, is used.
The Header Length field contains the length of the WIMP-F header and
the length of parameters in 8 bytes units, excluding the first 8
bytes. Since all WIMP-F headers MUST contain the sender's and
receiver's CID fields, the minimum value for this field is 4, and
conversely, the maximum length of the WIMP-F Parameters field is
(255*8)-32 = 2008 bytes.
The Packet Type indicates the WIMP-F packet type. The individual
packet types are defined in the relevant sections. If a WIMP-F host
receives a packet that contains an unknown packet type, it MUST drop
the packet.
The Version is four bits. The current version is 1. The version
number is expected to be incremented only if there are incompatible
changes to the protocol. Most extensions can be handled by defining
new packet types, new parameter types, or new controls.
The following four bits are reserved for future use. They MUST be
zero when sent, and they SHOULD be ignored when handling a received
packet.
Ylitalo, et al. Expires November 30, 2004 [Page 23]
Internet-Draft WIMP-F June 2004
The CID fields are always 128 bits (16 bytes) long.
6.1.1 WIMP-F Controls
The WIMP-F control section transfers information about the structure
of the packet and capabilities of the host.
The following fields have been defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | |P| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P - Piggy backing The sending host is capable of sending and
receiving additional data in WIMP-F packets.
The rest of the fields are reserved for future use and MUST be set to
zero on sent packets and ignored on received packets.
6.1.2 Checksum
If WIMP-F messages are sent in UDP datagrams the checksum field in
the WIMP-F header is set to zero.
If WIMP-F messages are implemented as IP extension headers, the
checksum is calculated in the following way. The pseudo-header [1]
contains the source and destination IPv6 addresses, WIMP-F packet
length in the pseudo-header length field, a zero field, and the
WIMP-F protocol number (TBD) in the Next Header field. The length
field is in bytes and can be calculated from the WIMP-F header length
field: (WIMP-F Header Length + 1) * 8.
6.2 TLV format
The TLV encoded parameters are described in the following
subsections. The type-field value also describes the order of these
fields in the packet. The parameters MUST be included into the
packet so that the types form an increasing order. If the order does
not follow this rule, the packet is considered to be malformed and it
MUST be discarded.
All the TLV parameters have a length which is a multiple of 8 bytes.
When needed, padding MUST be added to the end of the parameter so
that the total length becomes a multiple of 8 bytes. This rule
ensures proper alignment of data. If padding is added, the Length
field MUST NOT include the padding. Any added padding bytes MUST be
set zero by the sender, but their content SHOULD NOT be checked on
the receiving end.
Ylitalo, et al. Expires November 30, 2004 [Page 24]
Internet-Draft WIMP-F June 2004
Consequently, the Length field indicates the length of the Contents
field (in bytes). The total length of the TLV parameter (including
Type, Length, Contents, and Padding) is related to the Length field
according to the following formula:
Total Length = 11 + Length - (Length + 3) % 8;
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter
C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, zero otherwise.
The C bit is considered to be a part of the Type field.
Consequently, critical parameters are always odd
and non-critical ones have an even value.
Length Length of the parameter, in bytes.
Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed
Critical parameters MUST be recognized by the recipient. If a
recipient encounters a critical parameter that it does not recognize,
it MUST NOT process the packet any further.
Non-critical parameters MAY be safely ignored. If a recipient
encounters a non-critical parameter that it does not recognize, it
SHOULD proceed as if the parameter was not present in the received
packet.
Ylitalo, et al. Expires November 30, 2004 [Page 25]
Internet-Draft WIMP-F June 2004
6.2.1 HMAC-INIT
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65500
Length 20
HMAC
HMAC-SHA1 is computed over:
- WIMP-F common header,
- CIDT TLV, of the initiator,
- LSET TLV, of the initiator
- CHALLENGE TLV, of the initiator,
excluding the HMAC-INIT TLV. The checksum field MUST
be set to zero and the WIMP-F header length in the WIMP-F
common header MUST be calculated to cover all the included
parameters when the HMAC-SHA1 is calculated. The key is
the first unrevealed hash value of the Initiator.
HMAC-INIT calculation and verification process:
INIT message sender:
1. Create the INIT message, containing CIDT, LSET and CHALLENGE
TLVs, without the HMAC-INIT TLV.
2. Calculate the length field in the WIMP-F header.
3. Compute the HMAC-SHA1.
4. remove the CIDT and LSET TLVs.
5. Add the HMAC-INIT TLV and optional TLVs to the packet.
6. Recalculate the length field in the WIMP-F header.
CCR message receiver:
Ylitalo, et al. Expires November 30, 2004 [Page 26]
Internet-Draft WIMP-F June 2004
1. Create the INIT message, containing CIDT, LSET and CHALLENGE
TLVs, without the HMAC-INIT TLV.
2. Calculate the length in the WIMP-F header and clear the checksum
field (set it to all zeros).
3. Compute the HMAC-SHA1 and verify it against the received
HMAC-INIT TLV.
6.2.2 HMAC-CC
The TLV structure is the same as in Section 6.2.1. The fields are:
Type 65502
Length 20
HMAC
HMAC-SHA1 is computed over:
- WIMP-F common header.
- HMAC-INIT TLV, received in the INIT message,
- CHALLENGE TLV, of the responder,
- LSET TLV, of the responder,
excluding the HMAC-CC parameter. The checksum field MUST
be set to zero and the WIMP-F header length in the WIMP-F
common header MUST be calculated to cover all the included
parameters when the SHA1 is calculated. The key is the
the first unrevealed hash value of the responder.
HMAC-CC calculation and verification process:
CC message sender:
1. Create the CC message, containing HMAC-INIT, CHALLENGE and LSET
TLVs, without HMAC-CC TLV.
2. Calculate the length field in the WIMP-F header.
3. Compute the HMAC-SHA1.
4. Add the HMAC-CC TLV and HASVAL TLV to the packet.
5. Recalculate the length field in the WIMP-F header.
CCR and CONF message receiver:
Ylitalo, et al. Expires November 30, 2004 [Page 27]
Internet-Draft WIMP-F June 2004
1. Create the CC message, containing HMAC-INIT, CHALLENGE and LSET
TLVs, without HMAC-CC and HASHVAL TLVs.
2. Calculate the length field in the WIMP-F header and clear the
checksum field (set it to all zeros).
3. Compute the HMAC-SHA1 and verify it against the received HMAC-CC.
6.2.3 HMAC-BOOTSTRAP
The TLV structure is the same as in Section 6.2.1. The fields are:
Type 65504
Length 20
HMAC
HMAC-SHA1 is computed over:
- WIMP-F common header,
- LSET TLV, of the initiator,
- ANCHOR TLV, of the initiator,
- CHALLENGE TLV, of the initiator,
excluding the HMAC-BOOTSTRAP parameter. The checksum
field MUST be set to zero and the WIMP-F header length
in the WIMP-F common header MUST be calculated to cover
all the included parameters when the SHA1 is calculated.
The key is the first unrevealed hash value of the initiator's
hash chain.
HMAC-BOOTSTRAP calculation and verification process.
BOOTSTRAP message sender:
1. Create the BOOTSTRAP message, containing LSET, ANCHOR, and
CHALLENGE TLVs, without HMAC-BOOTSTRAP and HASHVAL TLVs.
2. Calculate the length field in the WIMP-F header.
3. Compute the HMAC-SHA1.
4. Add the HMAC-CC and HASHVAL TLVs to the packet.
5. Recalculate the length field in the WIMP-F header.
ACR message receiver:
Ylitalo, et al. Expires November 30, 2004 [Page 28]
Internet-Draft WIMP-F June 2004
1. Create the BOOTSTRAP message, containing LSET, ANCHOR, and
CHALLENGE TLVs, without HMAC-BOOTSTRAP and HASHVAL TLVs.
2. Calculate the length field in the WIMP-F header and clear the
checksum field (set it to all zeros).
3. Compute the HMAC-SHA1 and verify it against the received
HMAC-BOOTSTRAP.
6.2.4 HASHVAL
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chain ID | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Hash |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 12
Length 28
Chain ID Identifier of the Hash Chain.
Count The number of a hash chain value in the hash chain.
zero means an anchor value.
Reserved Zero when sent, ignored when received
Hash 160 bit SHA1 hash value.
6.2.5 ANCHOR
The TLV structure is the same as in Section 6.2.4. The fields are:
Type 10
Length 28
Count 0 (an anchor value).
Reserved Zero when sent, ignored when received
Hash 160 bit SHA1 hash value.
Ylitalo, et al. Expires November 30, 2004 [Page 29]
Internet-Draft WIMP-F June 2004
6.2.6 CIDT
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ID | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16
Length (variable)
Context ID context identifier (e.g. flowid or SPI)
6.2.7 CHALLENGE
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 20
Length 20
Reserved Zero when sent, ignored when received
Challenge 128 bit (16 bytes) random number
Ylitalo, et al. Expires November 30, 2004 [Page 30]
Internet-Draft WIMP-F June 2004
6.2.8 LSET
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator #1 |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator #n |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 22
Length variable
Reserved Zero when sent, ignored when received
Locator IPv6 address (or IPv4 address in IPv6 format)
6.2.9 KEY
Ylitalo, et al. Expires November 30, 2004 [Page 31]
Internet-Draft WIMP-F June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chain ID | Hash count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID | Key Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key piece 160 bit (AC message) / |
/ Combined key 160 bit (ACR message) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
Length 40
Reserved Zero when sent, ignored when received
Chain ID Identifier of the Hash Chain.
Hash Count The number of a hash chain value in the responder's
hash chain. The hash chain value that is divided into key
pieces.
AC ID An increasing counter that identifies the exchange with CIDs.
Key count The total number of key pieces sent/received
Key Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The responder defines a bit in the mask for a key piece.
Key piece A hash chain value is divided into (160 bit) key pieces
by the responder.
Combined key The initiator constructs a combined key using the key
pieces.
The AC ID is related to a divided secret, i.e., a hash chain value.
Every key piece related to that value must have the same AC ID.
Responder sending AC message:
The key count field value in the AC packet is the total number of key
pieces sent by the responder, i.e. the total number of AC packets.
Each KEY-MASK TLV in one AC packet contains a key piece having a
corresponding bit on in the key mask field
Ylitalo, et al. Expires November 30, 2004 [Page 32]
Internet-Draft WIMP-F June 2004
(Note: The responder is able to make a reachability test maximum for
32 locators per divided key. However, it typically verifies the
locators on demand basis.)
Initiator sending ACR message:
The initiator makes an OR -operation for all received key masks in
the AC packets. The result of the operation is included in the
KEY-MASK TLV in the ACR message.The key count field in KEY-MASK TLV
in the ACR message indicates the number of key pieces the initiator
received from the responder. The combined key is included into the
KEY-MASK TLV.
7. Packet processing
7.1 Processing outgoing application data
In an WIMP-F host, an application can send application level data
using AIDs as source and destination identifiers. However, whenever
there is such outgoing data, the stack has to send the resulting
datagram using appropriate source and destination IP addresses.
The following steps define the conceptual processing rules for
outgoing datagrams destinated to a AID(R).
1. If the datagram has a specified source AID(I), it MUST be one of
the locators.
2. If the datagram has an unspecified AID(I), the implementation
MUST choose a suitable source AID(I) for the datagram. In
selecting a proper AID(I), the implementation MUST consult the
table of currently active WIMP-F sessions, and preferably select
an AID(I) that already has an active session with the target
AID(R).
3. If there is no active WIMP-F session with the AID(R), one may be
created by running the context establishment exchange. The INIT
packet is sent to the AID(R). The host selects a CID(I) and
optionally CID(R) for the context establishment exchange. At
latest, the context must be established when the AID(I) differs
from the selected source locator.
4. Once there is an active WIMP session for the given AID(R), the
AID(R) must match one of the locators in the context. The CIDs
are represented by CIDTs in the IP payload packets.
5. The AIDs in the datagram are replaced with suitable locators.
Ylitalo, et al. Expires November 30, 2004 [Page 33]
Internet-Draft WIMP-F June 2004
7.2 Processing incoming application data
Incoming WIMP-F datagrams arrive as normal IP packets containing
CIDT. In the usual case the receiving host has a corresponding
host-pair context, identified by the CIDT and a locator-pair in the
packet. However, if the host has crashed or otherwise lost its
state, it may not have such a host-pair context.
The following steps define the conceptual processing rules for
incoming datagrams targeted to a WIMP-F host-pair context.
1. If the packet does not contains CIDT, it is sent to the upper
layer without processing.
2. If a proper host-pair context is detected, using the CIDT and
locator-pair, the packet is processed by the wedge layer. If
there are no host-pair context identified with the specific CIDT,
the host MAY reply with a SYNC packet.
3. If a proper host-pair context is found, the packet is processed
by WIMP-F. The locators in the datagram are replaced with the
AIDs associated with the host-pair context.
8. State Machine
Each host is assumed to have a separate WIMP-F implementation that
manages the host-pair contexts and handles requests for new ones.
Each host-pair context is governed by a state machine. WIMP-F
implementation can simultaneously maintain host-pair contexts with
more than one host. Furthermore, WIMP-F implementation may have more
than one active host-pair context with another host; in this case,
host-pair contexts are distinguished by their respective CIDs. It is
not possible to have more than one host-pair contexts between any
given pair of CIDs. Consequently, the only way for two hosts to have
more than one parallel associations is to use different CIDs, at
least in one end.
The processing of packets depends on the state of the host-pair
context(s) with respect to the originator of the packet. A WIMP-F
implementation determines whether it has an active association with
the originator of the packet based on the CIDs or the context
identifier, CIDT, in the IP packet.
The state machine is presented in a single system view, representing
either an Initiator or a Responder. There is not a complete overlap
of processing logic here and in the packet definitions. Both are
needed to completely implement WIMP-F.
Ylitalo, et al. Expires November 30, 2004 [Page 34]
Internet-Draft WIMP-F June 2004
Implementors must understand that the state machine, as described
here, is informational. Specific implementations are free to
implement the actual functions differently.
States:
START , state machine start
INIT-sent , INIT sent by initiator
CCR-sent , CCR sent by initiator
ESTABLISHED , host-pair context established
ESTABLISHED-BOOTSTRAP-sent , BOOTSTRAP sent
ESTABLISHED-AC-sent , AC sent without receiving BOOTSTRAP message.
FAILED , host-pair context establishment failed
State Processes:
+---------+
| START |
+---------+
Context establishment request, send INIT and go to INIT-send
Receive INIT, send CC and stay at START
Receive CCR, process
if successfull, send CONF and go to ESTABLISHED
if fail, stay at START
Receive IP packet without context, send SYNC and stay at START
Receive ANYOTHER, drop and stay at START
+-----------+
| INIT-sent |
+-----------+
Receive INIT, send CC and stay at INIT-sent
Receive CCR, process
if successful, send CONF and go to ESTABLISHED
if fail, stay at INIT-sent
Receive CC, process
if successful, send CCR and go to CCR-sent
if fail, stay at INIT-sent
Receive SYNC, process
if successful, send INIT, and stay at INIT-sent
if fail, change CID(I), send INIT, and stay at INIT-sent, or
Ylitalo, et al. Expires November 30, 2004 [Page 35]
Internet-Draft WIMP-F June 2004
if fail, start another exchange supporting strong authentication,
and stay at INIT-sent, or
if fail, go to FAILED
Receive ANYOTHER, drop and stay at INIT-sent
Timeout, increment timeout counter
If counter is less than INIT_RETRIES_MAX, send INIT,
and stay at INIT-sent
If counter is greater than INIT_RETRIES_MAX, go to FAILED
+----------+
| CCR-sent |
+----------+
Receive INIT, send CC and stay at CCR-sent
Receive CCR, process
if successful, send CONF and go to ESTABLISHED
if fail, stay at CCR-SENT
Receive CONF, process
if successful, go to ESTABLISHED
if fail, stay at CCR-SENT
Receive ANYOTHER, drop and stay at CCR-sent
Timeout, increment timeout counter
If counter is less than CCR_RETRIES_MAX, send CCR and stay at CCR-sent
If counter is greater than CCR_RETRIES_MAX, go to FAILED
+-------------+
| ESTABLISHED |
+-------------+
BOOTSTRAP to send, go to ESTABLISHED-BOOTSTRAP-sent
AC to send, go to ESTABLISHED-AC-sent
Receive BOOTSTRAP, process
if successful, send AC(s), and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive AC, process
if successful, send ACR, and stay at ESTABLISHED
if fail, drop and stay at ESTABLISHED
Receive ACR, process
if successful, update context, and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive IP packet for context, process and stay at ESTABLISHED
Receive SYNC, process
if successful, send INIT, and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive CC, process
if successful, update context, send CCR, and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive CONF, process
Ylitalo, et al. Expires November 30, 2004 [Page 36]
Internet-Draft WIMP-F June 2004
if successful, update context, and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive ANYOTHER, drop and stay at ESTABLISHED
+-----------------------------+
| ESTABLISHED-BOOTSTRAP-sent | (for full re-addresing exchange)
+-----------------------------+
Receive AC, process
if successful, send ACR, and go to ESTABLISHED
if fail, drop and cycle at ESTABLISHED-BOOTSTRAP-sent
Receive BOOTSTRAP, process
if successful, send AC(s), and stay at ESTABLISHED-BOOTSTRAP-sent
if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent
Receive ACR, process
if successful, update context, and stay at
ESTABLISHED-BOOTSTRAP-sent
if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent
Receive SYNC, process
if successful, send INIT, and stay at ESTABLISHED-BOOTSTRAP-sent
if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent
Receive CC, process
if successful, update context, send CCR, and go to ESTABLISHED
if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent
Receive IP packet for context, process and stay at ESTABLISHED-BOOTSTRAP-sent
Receive ANYOTHER, drop and stay at ESTABLISHED-BOOTSTRAP-sent
Timeout, increment timeout counter
If counter is less than BOOTSTRAP_RETRIES_MAX,
send BOOTSTRAP to another locator,
and stay at ESTABLISHED-BOOTSTRAP-sent
If counter is greater than BOOTSTRAP_RETRIES_MAX, go to FAILED
+----------------------+
| ESTABLISHED-AC-sent | (for dynamic AC-ACR reachability test)
+----------------------+
Receive AC, process
if successful, send ACR, and stay at ESTABLISHED-AC-sent
if fail, drop and cycle at ESTABLISHED-AC-sent
Receive BOOTSTRAP, process
if successful, send AC, and stay at ESTABLISHED-AC-sent
if fail, drop, and stay at ESTABLISHED-AC-sent
Receive ACR, process
if successful, update context, and go to ESTABLISHED
if fail, drop, and stay at ESTABLISHED-AC-sent
Receive SYNC, process
if successful, send INIT, and stay at ESTABLISHED-AC-sent
if fail, drop, and stay at ESTABLISHED-AC-sent
Receive CC, process
if successful, update context, send CCR, and go to ESTABLISHED
Ylitalo, et al. Expires November 30, 2004 [Page 37]
Internet-Draft WIMP-F June 2004
if fail, drop, and stay at ESTABLISHED-AC-sent
Receive IP packet for context, process and stay at ESTABLISHED-AC-sent
Receive ANYOTHER, drop and stay at ESTABLISHED-AC-sent
Timeout, increment timeout counter
If counter is less than AC_RETRIES_MAX, send AC to another locator,
and stay at ESTABLISHED-AC-sent
If counter is greater than AC_RETRIES_MAX, go to FAILED
9. Security Considerations
The main objective in WIMP-F is to use one-way hash chains instead of
public key cryptography. The reason for this is that there exists
already a group of authenticated Diffie-Hellman key exchange
protocols. Protocols using public key cryptography are often
vulnerable for different kind of CPU related denial-of-service
attacks. The trade-off between hash chain based message
authentication and signatures is that the former is vulnerable for a
class of man-in-the-middle attacks. However, if we accept that the
first round-trip of the context establishment exchange is open for
such attacks we obtain several advantages. The hash chain and HMAC
computation are very lightweight operations compared to public key
signing and signature verification.
9.1 Context establishment exchange
9.1.1 Man-in-the-Middle attacks
The context establishment exchange is based on opportunistic
authentication. In other words, both hosts, the initiator and the
responder, blindly trust to each other during the first round-trip.
The responder trusts that the INIT message comes from an authentic
initiator. In a similar way, the initiator trusts that the CC
message comes from an authentic responder. Thus, the first
round-trip is vulnerable for the MitM attacks.
Basically, the first round-trip of the exchange also bootstraps the
hash chains. The initiator's anchor is sent in the third message,
but the HMAC binds the first and the third messages together. A MitM
attacker cannot later change any values in the CCR message, because
the parameters are authenticated with the initiator's HMAC-INIT.
Further, the HMAC-INIT is protected with the responder's HMAC-CC. In
this way, the responder does not need to establish a state once it
receives INIT message.
An eavesdropper, listening INIT messages, cannot reserve a host-pair
context by sending CCR message before the initiator, because the
HMACs bind the messages together. Basically, the hash chains have
Ylitalo, et al. Expires November 30, 2004 [Page 38]
Internet-Draft WIMP-F June 2004
two main purposes. They bind messages together, and they are used
for authentication. The hash chain properties were discussed in more
detail in Section 3.
9.1.2 Denial-of-Service attacks
The initiator may use any kind of identifier, CID(I), it wants with
the responder, an ephemeral or a fixed identifier. The ephemeral
identifier protects the initiator from a specific form of DoS attack.
That is, an attacker cannot guess the initiator's identifier and
reserve a state at the responder. If the initiator decides to use
fixed identifiers it MAY need prove to the responder, using public
key cryptography, that it owns the identifier.
The beginning of the WIMP-F context establishment exchange is
stateless for the responder, in order to avoid attacks where the
attacker is trying to create inconsistent states at the responder.
The responder makes a kind of reachability test before establishing a
state with the initiator. The initiator has to prove that it is
reachable at the location where it sent the initial packet. The
responder MAY optionally restrict establishing a host-pair context
with CID(I) if the responder already has several host-pair contexts
related to the corresponding locator. This restrictions reduces the
need of using any challenge puzzle (See HIP) in the CC message.
The context establishment protocol is vulnerable for a context
identifier, CIDT(R), related attack. The only parameter that is not
protected with HMAC is the responder's CIDT in the last message. The
reason for this is that the responder cannot reserve any values
before it creates a state. The state is created after receiving the
CCR message. As a result, the responder cannot include the CIDT into
its HMAC in the CC message. a MitM attacker may change the
responder's CIDT on the fly in the last message and course a
denial-of-service situation. In other words, the responder will send
IP packets with unrecognized context identifier to the initiator.
However, the main objective of the protocol is to protect the hosts
from the re-direction attacks and the presented attack does not open
new vulnerabilities for that part of the protocol.
9.1.3 Cryptanalysis based on the state loss procedure
An attacker may apply the re-synchronization procedure to make
cryptanalysis. The attacker may try to pump up a full hash chain of
the responder. The attacker sends a storm of INIT packets, each of
them containing different random challenge, CHALLENGE(R), and hash
chain, HASHVAL(R), values. The destination identifier must match
with the responder's identifier, but the initiator may freely select
its own identifier. The responder drops the INIT packet, if the
Ylitalo, et al. Expires November 30, 2004 [Page 39]
Internet-Draft WIMP-F June 2004
received hash value is not a member of the reconstructed hash chain.
However, if the attacker manages to make a correct guess, the
responder responds with CC packet containing the successor value of
its hash chain. The attacker can send a new INIT message containing
the received successor value and the challenge that was used to
generate that hash chain. Finally, the attacker finds out the whole
hash chain.
The attacker must make the attack beforehand, because the responder
does not reply with CC message, if it has already a context for the
CIDs. In addition, the responder generates a fresh challenge for
every new hash chain, and thus it is statistically hard to guess the
correct combination that matches with the CIDs and the challenge. An
ephemeral identifier of the initiator makes the attack more
difficult.
It may be possible that an attacker is able to make cryptanalysis
about the responder's secret applying the previous attack. (The
probability and difficultness of such an attack is TBD. Thus, the
secret should be changed every TBD. If the attacker is able to find
out the responder's secret, it may impersonate itself to a responder,
and launch an attack by sending SYNC message to the initiator. The
initiator sends the INIT packet to one of the responder's locators
and verifies if the responder has rebooted. This attack requires
that the attacker is able to listen the traffic between the inititor
and the responder. Otherwise, the attacker cannot reply with the
correct CC message, including the initiator's HMAC_INIT. A
successful attack results in that the initiator updates its context
with the attacker. (Note: It is still good to notice that WIMP-F is
a semi-strong authentication protocol that does not require much
computation power. If strong authentication is required some public
key based protocol, should be used.)
9.2 Re-addressing exchange
A host must inform its peers about the new locator(s) after site
renumbering. The sender of the new locator set is called the
initiator. Once the responder receives BOOTSTRAP message it cannot
trust the initiator is reachable at the new location(s). To avoid
different kind of DoS and re-direction attacks the responder must
verify that the initiator is indeed reachable at the claimed
location(s).
WIMP-F takes advantage of parallel paths between the hosts. The
responder splits its hash chain value into pieces and includes one
piece to each challenge (AC) message. The challenge messages are
sent to different locators. As a result, an attacker has to locate
at different topological locations, at the same time, to be able to
Ylitalo, et al. Expires November 30, 2004 [Page 40]
Internet-Draft WIMP-F June 2004
answer to the challenge. The initiator, in turn, is able to verify
that all of the pieces came from the authentic responder. The secret
splitting works only if there are more than one destination locators
and the messages are routed via different paths to the initiator.
10. IANA Considerations
TBD.
11. Acknowledgments
The initial version of this draft was written after a discussion
between the authors, Pekka Nikander and Jari Arkko at the 58th IETF.
The focus in this draft has been on authenticating the hosts to their
peers with one-way hash chains. Instead of inventing the wheel once
again, we took several ideas from the existing multi-homing protocol
proposals. Thus, there are certain similarities, e.g., with NOID and
HIP design factors. We would like to thank all contributers in those
drafts who have affected the work.
The authors would especially like to thank the following people who
have given valuable feedback about WIMP (the names are in
alphabetical order): Jari Arkko, Marcelo Bagnulo, Iljitsch van
Beijnum, Gonzalo Camarillo, Brian E. Carpenter, Dave Crocker, Joel
M. Halpern, Pekka Nikander, Ayyasamy Senthilkumar, and Margaret
Wasserman.
12. References
12.1 Normative references
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
12.2 Informative references
[2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[3] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
solutions", draft-nordmark-multi6-threats-00.txt (work in
progress), October 2003.
[4] Shamir, A., "How to Share a Secret", Comm. of the ACM
22(11):612- 613, November 1979.
[5] Blakely, G., "Safeguarding Cryptographic Keys", In Proc. AFIPS
National Computer Conference pp. 313-317, 1979.
Ylitalo, et al. Expires November 30, 2004 [Page 41]
Internet-Draft WIMP-F June 2004
[6] Canetti, R., Song, D. and D. Tygar, "Efficient Authentication
and Signing of Multicast Streams over Lossy Channels", , May
2000.
[7] Lamport, L., "Password authentication with insecure
communication", Commun. Mag. of ACM 24 (11), pp. 770-772, 1981.
Authors' Addresses
Jukka Ylitalo
Ericsson Research Nomadiclab
Jorvas FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: jukka.ylitalo@ericsson.com
Vesa Torvinen
Ericsson Research Nomadiclab
Turku FIN-20520
FINLAND
Phone: +358 9 299 1
EMail: vesa.torvinen@ericsson.com
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Ylitalo, et al. Expires November 30, 2004 [Page 42]
Internet-Draft WIMP-F June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ylitalo, et al. Expires November 30, 2004 [Page 43]