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]