idnits 2.17.1 draft-ylitalo-multi6-wimp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1933. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1949), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '... each hash chain MUST be used only onc...' RFC 2119 keyword, line 459: '... Each hash chain MUST be bound to end-...' RFC 2119 keyword, line 462: '... Each hash chain MUST be bound to a lo...' RFC 2119 keyword, line 466: '...s problem. The responder SHOULD reuse...' RFC 2119 keyword, line 470: '... Each hash chain MUST be bound to a ra...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 1865, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Ylitalo 2 Internet-Draft V. Torvinen 3 Expires: November 30, 2004 Ericsson Research Nomadiclab 4 E. Nordmark 5 Sun Microsystems, Inc. 6 June 2004 8 Weak Identifier Multihoming Protocol Framework (WIMP-F) 9 draft-ylitalo-multi6-wimp-01 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 30, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 Weak Identifier Multihoming Protocol Framework (WIMP-F) is a wedge 43 layer 3.5 framework to be applied with different kind of routable 44 application layer identifiers (AIDs) and layer 3.5 context 45 identifiers (CIDs) presented in Group-F. WIMP-F consists of context 46 establishment and re-addressing exchanges that are protected with 47 one-way hash chains and a technique called as secret splitting. The 48 hash chain protects a host from re-direction attacks, but not 49 directly from an CID or AID theft. The ownerships can be provided in 50 variable ways presented in other Multi6 drafts. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 56 3. Cryptographic techniques used in WIMP-F . . . . . . . . . . . 5 57 3.1 One-Way hash chain . . . . . . . . . . . . . . . . . . . . 5 58 3.2 One-Way hash chain and message authentication . . . . . . 6 59 3.3 Chained bootstrapping . . . . . . . . . . . . . . . . . . 6 60 3.4 Secret splitting . . . . . . . . . . . . . . . . . . . . . 7 61 4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1 Wedge layer . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2 Translation between AIDs and Locators . . . . . . . . . . 9 64 4.3 Host-Pair Context . . . . . . . . . . . . . . . . . . . . 10 65 4.4 Generating one-way hash chains . . . . . . . . . . . . . . 11 66 4.5 Context establishment exchange . . . . . . . . . . . . . . 12 67 4.5.1 State Loss . . . . . . . . . . . . . . . . . . . . . . 14 68 4.5.2 Identity theft or the initiator has lost its state? . 14 69 4.5.3 Responder has lost its state . . . . . . . . . . . . . 16 70 4.6 Re-addressing exchange . . . . . . . . . . . . . . . . . . 18 71 5. Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 5.1 INIT - the context initiator packet . . . . . . . . . . . 20 73 5.2 CC - the context check packet . . . . . . . . . . . . . . 20 74 5.3 CCR - the context check reply packet . . . . . . . . . . . 20 75 5.4 CONF - the context confirm packet . . . . . . . . . . . . 21 76 5.5 BOOTSTRAP - The bootstrapping packet . . . . . . . . . . . 21 77 5.6 AC - The address check packet . . . . . . . . . . . . . . 21 78 5.7 ACR - The address check reply packet . . . . . . . . . . . 22 79 5.8 SYNC - The re-synchronization packet . . . . . . . . . . . 22 80 6. Message formats . . . . . . . . . . . . . . . . . . . . . . . 22 81 6.1 Header format . . . . . . . . . . . . . . . . . . . . . . 22 82 6.1.1 WIMP-F Controls . . . . . . . . . . . . . . . . . . . 24 83 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 24 84 6.2 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.2.1 HMAC-INIT . . . . . . . . . . . . . . . . . . . . . . 26 86 6.2.2 HMAC-CC . . . . . . . . . . . . . . . . . . . . . . . 27 87 6.2.3 HMAC-BOOTSTRAP . . . . . . . . . . . . . . . . . . . . 28 88 6.2.4 HASHVAL . . . . . . . . . . . . . . . . . . . . . . . 29 89 6.2.5 ANCHOR . . . . . . . . . . . . . . . . . . . . . . . . 29 90 6.2.6 CIDT . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 6.2.7 CHALLENGE . . . . . . . . . . . . . . . . . . . . . . 30 92 6.2.8 LSET . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 6.2.9 KEY . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 7. Packet processing . . . . . . . . . . . . . . . . . . . . . . 33 95 7.1 Processing outgoing application data . . . . . . . . . . . 33 96 7.2 Processing incoming application data . . . . . . . . . . . 34 98 8. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 34 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 100 9.1 Context establishment exchange . . . . . . . . . . . . . . 38 101 9.1.1 Man-in-the-Middle attacks . . . . . . . . . . . . . . 38 102 9.1.2 Denial-of-Service attacks . . . . . . . . . . . . . . 39 103 9.1.3 Cryptanalysis based on the state loss procedure . . . 39 104 9.2 Re-addressing exchange . . . . . . . . . . . . . . . . . . 40 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 106 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 108 12.1 Normative references . . . . . . . . . . . . . . . . . . . . 41 109 12.2 Informative references . . . . . . . . . . . . . . . . . . . 41 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 111 Intellectual Property and Copyright Statements . . . . . . . . 43 113 1. Introduction 115 The reason to name this draft as WIMP-F is that it relies on the same 116 one-way hash chain procedures as the initial version of WIMP. 117 However, this draft does not define new application layer identifiers 118 (AIDs). The WIMP-F exchanges are designed to support any kind of 119 128-bits AIDs and layer 3.5 context identifiers (CIDs). By default, 120 the ownership of AIDs can be proved by the reachability test 121 implemented by the context establishment exchange. A separate 122 ephemeral CID layer 3.5 namespace can be used to protect host from 123 CID theft. 125 WIMP-F offers a context establishment and locator update exchanges 126 for other Group-F identifiers. It protects hosts from re-direction 127 attacks by supporting one-way hash chains. Other Group-F protocols 128 applying WIMP-F are responsible for defining the properties of AIDs 129 and CIDs 131 WIMP-F defines a new service at the IP layer rather than a new layer 132 in the stack. It assumes that AIDs are routable from their nature, 133 and there is one-to-many binding between the AIDs and the locators. 134 In other words, a single AID is bound to a IP layer locator set, but 135 it still has a locator role also itself. In addition, the AID may 136 also have cryptographical properties. If the AIDs are not 137 cryptographical from their nature, it may be possible to apply the 138 same framework also with IPv4 hosts. Therefore, the message 139 structures are designed to support both IPv6 and IPv4 hosts. 141 WIMP-F can be used to gradually update a legacy TCP connection to 142 Multi6 enabled connection depending on the Group-F design. 143 Furthermore, if WIMP-F protocol finds out that the responding party 144 has already a state for context identifier -pair, the initiating 145 party may change its context identifier or prove the identifier 146 ownership using some strong authentication mechanism, depending on 147 the type of context identifier. 149 2. Notational Conventions 151 - 'I' is an initiator. The party that initiates an exchange is 152 called an initiator. 154 - 'R' is a responder. 156 - Upper Layer Protocol (ULP). A protocol layer immediately above 157 IP. Examples are transport protocols such as TCP and UDP, control 158 protocols such as ICMP, routing protocols such as OSPF, and 159 internet or lower-layer protocols being "tunneled" over (i.e., 160 encapsulated in) IP such as IPX, AppleTalk, or IP itself. 162 - Application Identifier (AID). AID is a 128-bit routable IP 163 locator which has been selected for communication with a peer to 164 be used by the upper layer protocol. This is used for 165 pseudo-header checksum computation and connection identification 166 in the ULP. 168 - Context Identifier (CID). CID-pair is used by the wedge layer 169 to establish and identify the context during context establishment 170 and address update exchanges. A 128-bit CID may be the same as 171 the corresponding AID, or they may be separated from each other. 173 - Context Identifier Tag (CIDT). CIDT together with a 174 locator-pair are included in every payload packet to identify a 175 context. E.g. in NOID, the flowid, and in HIP, the SPI value. 176 CIDT is conceptually distinguished from the any specific field, so 177 that it can be used with any payload extension header. 179 - 'Ls' is a locator set consisting of L1, ... Ln. 181 - 'Hk' is k:th hash value in the hash chain. 'H0' is the first 182 revealed value, i.e. the "anchor" of the hash chain. Note that 183 the parameter k defines the revealing order, not the computation 184 order. 186 3. Cryptographic techniques used in WIMP-F 188 3.1 One-Way hash chain 190 One-Way hash chain [7] is cryptographically generated list of data 191 entities with some interesting characteristics. It is practically 192 impossible to calculate or otherwise figure out the next value in the 193 chain even when you know the previous value. However, it is very 194 easy to verify whether some given value is the next value or not. 196 The chain is created by recursively computing a hash function over a 197 result of the same function. The initial argument for the first hash 198 value computation is typically a large random number. The last 199 generated value of the chain is called as the "anchor" or "root" 200 value. The hash values are revealed in the reverse order starting 201 from the anchor value. 203 Hn = Hash(random number) 204 Hn-1 = Hash(Hn) 205 ... 206 H0 = anchor = Hash(H1) 208 CHAIN: H0,..,Hn 209 This technique is usually based on an assumption that only an 210 authentic end-point knows the correct successor values of the chain. 211 In the bootstrapping process, the end-point computes a new hash chain 212 and reveals the anchor value of the chain to its peer. It is 213 important to notice that each hash chain MUST be used only once. 215 3.2 One-Way hash chain and message authentication 217 Hashed Message Authentication Codes [2] are typically used to 218 authenticate messages with a symmetric key. This requires, 219 naturally, that all communicating peers share a secret. 221 One-Way hash chain values can be used as keys in the delayed message 222 authentication (see TESLA [6]). This is different from the shared 223 secret scheme, because anybody who is able to receive the subsequent 224 messages is able to verify that the messages belong together. The 225 one-way hash chain value (key) used in the message authentication is 226 not revealed before the next message. In other words, the peer is 227 able verify the message only after it has received the next message. 228 It is good to notice that a host must receive a confirmation message 229 before sending the next message to avoid delay attacks. This 230 procedure can be used to verify that all subsequent messages come 231 from the same entity than the first message. 233 A Man-in-the-Middle (MitM) attacker is not able to (unnoticeably) 234 modify the messages after the first message in the exchange. 235 However, an attacker may spoof the first message and use its own hash 236 chain. The protocol is based on opportunistic principle where the 237 peers trust that the initial message comes from the authentic host. 239 A -> B: Msg1(A), HMAC(H1(A), Msg1(A)) 240 A <- B: Msg1(B), HMAC(H1(B), Msg1(B)) 241 A -> B: Msg2(A), H1(A), HMAC(H2(A), Msg2(A)) 242 A <- B: Msg2(B), H1(B), HMAC(H2(B), Msg2(B)) 243 ... 244 A -> B: Msgn(A), Hn-1(A), HMAC(Hn(A), Msgn(A)) 245 A <- B: Msgn(B), Hn-1(A), HMAC(Hn(B), Msgn(B)) 246 A -> B: Hn(A) 247 A <- B: Hn(B) 249 3.3 Chained bootstrapping 251 In the basic model, each one-way hash chain is an independent entity. 252 This is not a problem if the anchor of the chain can be 253 authenticated, and if the hash chain is known to be long enough to 254 have values to every message in the communication session. However, 255 it is possible to use short hash chains to avoid extra computation. 257 Basically, the bootstrapping message can be authenticated using 258 public keys. In the WIMP-F approach, the peers do not authenticate 259 the bootstrapping message with a signature, but they rely on the 260 delayed message authentication. Two independently created one-way 261 hash chains can be linked together with HMAC computation. The last 262 value of the first one-way hash chain is used to authenticate the 263 first value of the second chain: 265 ... 266 A -> B: Msgn, H0new, Hn-1, HMAC(Hn, Msgn || H0new) 267 A <- B: (conf) 268 A -> B: Msgn+1, Hn, HMAC(H1new, Msgn+1) 269 A <- B: (conf) 270 A -> B: Msgn+2, H1new, HMAC(H2new, Msgn+2) 271 ... 273 3.4 Secret splitting 275 In secret splitting [4][5], a secret is divided into several pieces. 276 Any piece alone does not give enough information for an attacker to 277 create the original secret. The only way to create the secret is to 278 posses all the pieces. The splitting is done by generating 279 random-bit strings, the same length as the original secret. The key 280 splitting and secret reconstruction is done in the following way: 282 Constructing key pieces: 284 K_1 = nonce1 285 ... 286 K_k-1 = noncek-1 287 K_k = SECRET XOR K_1 ... XOR K_k-1 289 Combining the secret: 291 SECRET = K_1 XOR ... XOR K_k 293 Secret splitting is useful technique for storing secrets in two 294 physical places, or for sending a secret to the other end-point using 295 two or more parallel communication paths. 297 4. Protocol overview 299 The framework consists of AIDs, CIDs, CIDTs, and IP layer locators. 300 Each of them having a special role from the conceptual point of view. 301 In addition, the framework consists of mechanisms and policies. The 302 policies, like address selection policy, are out of this draft scope. 303 The mechanism are used to establish a context and prove the ownership 304 of the AID and the context. If AIDs are also used for wedge layer 305 CIDs, there is no reason to separate these two mechanisms from each 306 other, and AID ownership can be also used to prove the context 307 ownership. 309 WIMP-F supports, by default, locators without any cryptographical 310 properties. The weak ownership of routable AID is provided by the 311 implicit reachability during the context establishment. Otherwise, 312 this draft leaves open the security properties of the routable AIDs 313 and other mechanisms used to prove the ownership of the AID. It is 314 good to notice that proving the ownership of AID is an essential 315 mechanism in the final stand-alone Multi6 solution. However, 316 routable AIDs may have ephemeral suffixes making the guessing of AIDs 317 difficult for an attacker. However, in some cases it is not possible 318 to have such a randomness. The ownership of an AID could be e.g. 319 based on reverse DNS or public key based cryptography. 321 The IP layer locators are included in the address fields in the IP 322 packet headers. Further, each wedge 3.5 layer implementation must 323 establish a state, i.e. a context, for AID-locator bindings. The 324 context must be identified with some context identifier (CID) during 325 context establishment exchange. However, to avoid overhead in packet 326 sizes, it is possible to compress the CID and include a smaller CID 327 tag (CIDT) in every payload packet. CIDT is used together with a 328 locator-pair, in the IP header, to identify a context at the other 329 end-point. 331 The WIMP-F context establishment exchange is based on an 332 opportunistic principle. That is, a host does not care who its peer 333 is, as long as the peer is the same during the communication context 334 lifetime. The trust between the peers is established using one-way 335 hash chains during the initial exchange. The context owner is the 336 owner of the hash chain. Basically, the CID is just an index that 337 refers to a correct context. However, if an attacker is able to 338 guess or otherwise figure out the initiator's CID, the host becomes 339 vulnerable for context identifier theft. That is, an attacker tries 340 to establish a state using the identifier of the initiator. However, 341 it is possible to use ephemeral or cryptographically generated AIDs 342 as CIDs. In the latter case, a public key signature field must be 343 added (TBD) to the WIMP-F packet structures. In this case, the 344 responder should verify the ownership of the AID only after an AID 345 collision happens. Ephemeral port numbers helps to mitigate AID 346 ownership problem. However, when AIDs are used for CIDs, such an 347 extra randomness will disappear. 349 To protect from redirection attacks the presented protocol relies on 350 the ability to verify that the entity requesting redirection indeed 351 holds the successor values of a hash chain and is able to combine a 352 divided secret that is sent via parallel paths. WIMP-F offers 353 context establishment and re-addressing exchanges. The exchanges are 354 based on UDP, by default. The former exchange establishes a state 355 for both communication end-points. The re-addressing exchange is 356 used to implement reachability test and to update the locators 357 belonging to the communicating parties. 359 4.1 Wedge layer 361 +-----------------------------------+ 362 | Transport Protocols | 363 +-----------------------------------+ 364 | AH | ESP | Frag/reass | Dest opts | 365 +-----------------------------------+ 366 | Wedge layer | 367 +-----------------------------------+ 368 | IP | 369 ------------------------------------+ 371 Figure 1: Protocol stack 373 The proposal uses a wedge layer between IP and the ULPs as shown in 374 Figure 1, in order to provide ULP independence. Conceptually the 375 wedge layer behaves as if it is an extension header, which would be 376 ordered immediately after any hop-by-hop options in the packet. 377 Layering AH and ESP above the wedge layer means that IPsec can be 378 made to be unaware of locator changes the same way that transport 379 protocols can be unaware. Thus the IPsec security associations 380 remain stable even though the locators are changing. Layering the 381 fragmentation header above the wedge makes reassembly robust in the 382 case that there is broken multi-path routing which results in using 383 different paths, hence potentially different source locators, for 384 different fragments. 386 4.2 Translation between AIDs and Locators 388 Applications and upper layer protocols use AIDs which the wedge layer 389 will map to/from different locators. The wedge layer maintains 390 state, called host-pair context, in order to perform this mapping. 391 The mapping is performed consistently at the sender and the receiver, 392 thus from the perspective of the upper layer protocols packets appear 393 to be sent using AIDs from end to end, even though the packets travel 394 through the network containing locators in the IP address fields, and 395 even though those locators may be even rewritten in flight. 397 +--------------------+ +--------------------+ 398 | Initiator | | Responder | 399 | | | | 400 | ULP | | ULP | 401 | | src AID(I) | | ^ | 402 | | dst AID(R) | | | src AID(I) | 403 | v | | | dst AID(R) | 404 | WEDGE | | WEDGE | 405 | | src L1(I) | | ^ | 406 | | dst L1(R) | | | src L1(I) | 407 | v | | | dst L1(R) | 408 | IP | | IP | 409 +--------------------+ +--------------------+ 410 | ^ 411 +- cloud with some routers ----+ 413 Figure 2: Mapping identifiers to locators. 415 The result of this consistent mapping is that there is no impact on 416 the ULPs. In particular, there is no impact on pseudo-header 417 checksums and connection identification. 419 4.3 Host-Pair Context 421 The context establishment exchange establishes a state for both 422 communication end-points. The initiator creates a host-pair context 423 based on IDs and the locator set. The responder establishes a state 424 after receiving the second message from the initiator. 426 The context contains the following information: 428 - Context identifiers. 430 - Locator and locator status (e.g. if locator has been verified, 431 and which locators are preferred for communication) 433 - Hash chain information (e.g. parameters needed in the 434 construction of hash chains, last used local chains values, and 435 last known peer chain values) 437 Every IP packet must contain information about the related host-pair 438 context to find the the right one for the received packets. 439 Basically, it is possible to add an extra extension header to each 440 packet, containing a context identifier. This results into extra 441 overhead in the payload packets. On the other hand, a Multi6 442 protocol may include the context identifier into the IPv6 header 443 using, e.g., flowid field (NOID), or SPI value (HIP). Each Multi6 444 protocol defines own mechanism to map packets to Multi6 context. 446 Thus, WIMP-F context establishment exchange supports variable size 447 CIDTs. 449 4.4 Generating one-way hash chains 451 The hash chains are needed by the initiator and the responder during 452 the context establishment and re-addressing exchange. In addition, 453 the initiator bootstraps a new hash chain during every re-addressing 454 exchange. 456 WIMP-F sets the following requirements for the hash chains 457 generation: 459 - Each hash chain MUST be bound to end-point identifiers, i.e., 460 CID(I) and CID(R). 462 - Each hash chain MUST be bound to a local secret. Using the 463 local secret the responder does not need to establish a state 464 during the first round-trip in the context establishment exchange. 465 In addition, the local secret, stored in a persistent memory 466 system, solves the state loss problem. The responder SHOULD reuse 467 the same local secret with multiple initiators to avoid 468 establishing a state during the first round-trip. 470 - Each hash chain MUST be bound to a random string, i.e., a 471 challenge. The challenge makes each of the hash chains 472 statistically unique and protects the hosts from attackers that 473 try to find out hash chain values using spoofed identifiers. The 474 challenge is initially generated by the host that constructs the 475 related hash chain. 477 Initiator: 479 secret(I/R) = secret random number generated by I/R 480 challenge(I/R) = public random number generate by I/R 481 Hk(I/R) = hash chain value 482 ID(I/R) = end-point identifier 484 Hn(I) = SHA1(secret(I) || CID(I) || CID(R) || challenge(I)) 485 ... 486 H1(I) = SHA1(H2(I)) 487 H0(I) = SHA1(H1(I)) 489 Responder: 491 Hn(R) = SHA1(secret(R) || CID(R) || CID(I) || challenge(R)) 492 ... 493 H1(R) = SHA1(H2(R)) 494 H0(R) = SHA1(H1(R)) 496 The default length of both of the hash chains should be n=10. 497 Theoretically speaking, the minimum length of the hash chain is four 498 (4) hash values. This will last for one context establishment 499 exchange, and one re-addressing exchange for both directions. The 500 re-addressing exchange includes a bootstrapping procedure where a new 501 hash chain is created for the initiator. However, each unsuccessful 502 re-addressing exchange attempt will require one more hash chain 503 value. Failures in re-addressing exchange may be due to connection 504 loss in some of the locators, or an active attack. A host should 505 bootstrap a new hash chain at latest when it has only two hash values 506 left. 508 4.5 Context establishment exchange 510 The context establishment exchange bootstraps hash chains and creates 511 a state between two end-points. The protocol uses delayed 512 authentication procedure (see Section 3.2). The responder remains 513 stateless during the first round-trip. At the end of the exchange 514 both parties have a uniquely identifiable host-pair context 515 containing the peer's anchor value. 517 Initiator Responder 519 Construct hash chain. 520 Define CIDs and CIDT(I). 522 INIT: CIDs, challenge(I), [challenge_old(R), Hn_old(R)], 523 HMAC_INIT{H0(I), (CIDs || challenge(I) || CIDT(I) || Ls(I))} 524 --------------------------> 525 No host-pair context found. 526 Generate challenge(R). 527 Construct temporary hash chain. 529 CC: CIDs, HMAC_INIT, challenge(R), H0(R), Ls(R), 530 HMAC_CC{H1(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))} 531 <------------------------- 532 verify HMAC_INIT remain stateless 534 CCR: CIDs, HMAC_INIT, challenge(R), H0(R), challenge(I), 535 HMAC_CC, Ls(I), CIDT(I), H0(I) 536 --------------------------> 537 Reconstruct the hash chain. 538 Verify HMAC_INIT and HMAC_CC. 539 Define CIDT(R). 540 CONF: CIDs, H1(R), CIDT(R) 541 <-------------------------- 543 verify HMAC_CC 545 WIMP-F can be used with routable AIDs without cryptographical 546 properties, supporting separate ephemeral context identifier 547 namespace. In such a case, the context establishment is based on 548 opportunistic principle, and each host selects its context identifier 549 during the exchange. INIT contains Initiator's CID, but Responder's 550 CID is zero. Responder includes its CID in CC message. 552 The initiator triggers the exchange by sending a context 553 initialization message, INIT, to the responder. The INIT message 554 contains the CIDs, a challenge of the initiator and a HMAC. 555 Optionally, it contains also an old challenge and the last revealed 556 hash chain value of the responder (discussed later in Section 4.5.3). 558 The HMAC_INIT, having an anchor value as a key, is computed over the 559 CIDs, the context identifier, the challenge and the locator set of 560 the initiator. The context identifier and the locator set are sent 561 later in the context check reply message (CCR). The optional values 562 related to responder's old hash chain are not included into the 563 HMAC_INIT computation. 565 Once the responder receives the INIT message, it must check whether 566 it has already a host-pair context for the CID -pair. If a host-pair 567 context is found, the responder should assume that the initiator has 568 lost its state (discussed later in Section 4.5.2). If the context is 569 not found, but the INIT message contains responder's old challenge 570 and old hash chain value, the responder should assume it has lost its 571 state (discussed later in Section 4.5.3). In a typical case, when 572 the context is not found, and the INIT message does not contains any 573 optional values, the responder must continue the normal context 574 establishment exchange. 576 The responder must not establish a state after receiving the INIT, 577 because it cannot verify the origin of the message. In order to 578 remain stateless, the responder generates a fresh challenge and 579 computes a temporary hash chain, as presented in Section 4.4. The 580 context check (CC) message contains the CIDs, the received HMAC_INIT, 581 the responder's challenge, the anchor value, and the locator set. 582 The message is protected with the second value, H1(R), of responder's 583 hash chain. The initiator should make reachability test for every 584 received locator, in the Ls(R), before using it. (discussed later in 585 Section 4.6). 587 The initiator replies to the CC message with a context check reply 588 (CCR) message. The initiator proves that it was reachable at the 589 specific location by including the HMAC_CC into the message. Using 590 the responder's challenge and anchor value in the CCR message, the 591 responder can reconstruct the hash chain. The CCR message contains 592 the required information to establish a state and verify the 593 HMAC_INIT and HMAC_CC. The anchor value, H0(I), binds also the INIT 594 and CCR messages together. The responder should make a reachability 595 test for every received locator, in the Ls(I), before using it 596 (discussed later in Section 4.6). 598 The responder must drop a CCR packet with an ID pair that already has 599 a host pair-context. If the context is not found, the responder 600 reconstructs a hash chain and verifies the HMAC_CC and HMAC_INIT (in 601 this order). If the HMACs were valid, the responder creates a host 602 pair context using the CIDs. It also selects a context identifier, 603 CIDT(R), to be used in the payload packets. Finally, the responder 604 replies with a context confirmation message (CONF) revealing the 605 second hash value, H1(R). 607 The initiator verifies the HMAC_CC using the hash chain value 608 received in the CONF message, and finalizes its state. 610 4.5.1 State Loss 612 The context establishment exchange has been designed in the way that 613 it can be reused for secure re-synchronization. If a host receives a 614 valid SYNC message, it should start a new handshake with the INIT 615 message. The following scenarios describe the main use cases that 616 are covered by the design: 618 - The initiator does not have a host-pair context, but the 619 responder already has one for the CIDs. Either some host (e.g. 620 an attacker) is already using the the initiator's identifier, 621 ID(I), or the initiator has earlier lost its state. 623 - The initiator has a host-pair context, but the responder has 624 lost its state. 626 4.5.2 Identity theft or the initiator has lost its state? 628 If an initiator reboots or times out, it has lost its host-pair 629 context. The host does not have any prior state and sends INIT (see 630 Figure 10). If the responder finds out an active host-pair context 631 corresponding the CIDs, it compares the received challenge(I) with 632 the old challenge'(I) in the existing context. If the received 633 challenge(I) is different than the old one, it replies with the SYNC 634 message containing the initiator's old challenge'(I) and the latest 635 revealed hash chain value Hk'(I). If the received challenge(I) value 636 is the same with the old value, the responder replies with CC 637 message. 639 Once the initiator receives SYNC, it reconstructs the old hash chain 640 using the challenge'(I) and verifies that the Hk'(I) is a valid value 641 of that hash chain. If the verification fails the initiator MUST 642 drop the packet. Either 1) the packet was sent by an attacker or 2) 643 some other host is using the same ID(I). To protect from the former 644 attack, the initiator SHOULD wait for a while to receive a valid CC 645 or SYNC packet. Finally, if it does not receive a valid reply, it is 646 possible that an attacker has established a host-pair context with 647 the responder using the initiator's identifier (an identity theft). 649 The initiator has different alternatives to continue the exchange, 650 depending on the Group-F design. If possible, the initiator SHOULD 651 change its (ephemeral) CID and restart the exchange. If the 652 initiator is using a cryptographical identifier (e.g. HIT), it may 653 prove the ownership with signature included into the WIMP-F packet 654 (TBD) or start a public key based exchange (e.g. HIP base exchange), 655 using the same ID(I), to prove to the responder that it is the 656 authentic owner of the identifier. 658 However, if the Hk'(I), received in SYNC, was a valid hash chain 659 value, the initiator has probably lost its state. It SHOULD restart 660 the context establishment exchange by sending a new INIT message, 661 protected with a successor hash chain value, Hk+1'(I). 663 Once the responder receives the INIT message and challenge'(I) 664 matches with the one in the existing host-pair context, it replies 665 with CC. The message contains the old last revealed Hn(R), and the 666 corresponding challenge(R). The HMAC_RR is protected with the 667 successor value Hn+1(R). 669 The responder must drop the CCR message if the Hk+1'(I) verification 670 fails. If Hk+1(I) is valid hash chain value the responder replies 671 with CONF message, and reveals its successor hash chain value 672 Hn+1(R). 674 Initiator: Responder: 676 Latest revealed value=Hk'(I) Latest revealed value=Hn(R). 677 before state loss. 679 Send fresh INIT message 681 INIT: CIDs, challenge(I), 682 HMAC_INIT{H0(I), (CIDs || CIDT(I) || challenge(I) || Ls(I))} 683 --------------------------> 684 Host-pair context found. 685 No match with challenge'(I). 687 SYNC: CIDs, challenge'(I), Hk'(I) 688 <------------------------- 690 Reconstruct old hash chain 691 using challenge'(I). 692 Verify Hk'(I). 693 Restart exchange. 695 INIT: CIDs, challenge'(I), 696 HMAC_INIT{Hk+1'(I), (CIDs || CIDT(I) || challenge'(I) || Ls(I))} 697 --------------------------> 698 Host-pair context found. 699 Match with challenge'(I). 701 CC: CIDs, HMAC_INIT, challenge(R), Hn(R), Ls(R), 702 HMAC_CC{Hn+1(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))} 703 <------------------------- 705 CCR: CIDs, CIDT(I), Hk+1'(I), challenge'(I), Hn(R), 706 challenge(R), HMAC_INIT, HMAC_CC, Ls(I) 707 --------------------------> 708 verify Hk+1'(I) 709 verify HMAC_INIT and HMAC_CC 710 update host-pair context 711 CONF: CIDs, Hn+1(R), CIDT(R) 712 <-------------------------- 714 verify HMAC_CC 715 update host-pair context 717 Figure 10: Initiator has lost its state 719 4.5.3 Responder has lost its state 721 If a system receives an IP packet that does not match with any 722 host-pair context, the host has probably lost its state. The host 723 replies with SYNC message containing the context identifier that was 724 received in the IP packet (see Figure 11). Every IP packet must not 725 trigger a new SYNC message. The SYNC reply frequency must be rate 726 limited. 728 Once a host receives a SYNC message containing only a context 729 identifier, it should try to find a corresponding host-pair context. 730 If a host-pair context is found the host should send an INIT message 731 to verify whether the peer has lost its state. The initiator 732 includes the last revealed hash chain value, Hn(R), and corresponding 733 challenge(R) of the responder to the message. The initiator should 734 not generate new hash chain for itself, but use the successor value, 735 Hk+1(I), of the existing hash chain to protect the INIT message. 737 If the responder has a host-pair context for the CIDs, the SYNC 738 message was sent by an attacker, and the responder must drop the INIT 739 message containing the old hash chain and challenge values. If the 740 responder does not have a host-pair context for the CIDs, it should 741 reconstruct the old hash chain. The responder must verify that the 742 received hash chain value, Hn(R), is a valid member of the chain. If 743 the verification fails the responder must drop the INIT message. If 744 the Hn(R) is valid value, the responder includes the successor value, 745 Hn+1(R), into CC message, to prove that it has really lost its state. 746 The rest of the exchange is identical with the normal exchange, but 747 the responder must reveal the successor value, Hn+2(R), in the CONF 748 message. 750 Initiator: Responder: 752 Latest revealed value=Hk(I). Latest revealed value=Hn(R) 753 before state loss. 755 IP packet including CIDT(I) 756 --------------------------> 757 No host-pair context found 758 SYNC: CIDT(I) 759 <------------------------- 760 Find host-pair context. 761 Start exchange. 763 INIT: CIDs, challenge(R), Hn(R), 764 HMAC_INIT{Hk+1(I), (CIDs || CIDT(I) || challenge(I) || Ls(I))} 765 --------------------------> 766 No host-pair context found. 767 Construct old hash chain 768 using challenge(R). 769 Verify Hn(R). 771 CC: CIDs, HMAC_INIT, challenge(R), Hn+1(R), Ls(R), 772 HMAC_CC{Hn+2(R), (CIDs || HMAC_INIT || challenge(R) || Ls(R))} 773 <------------------------- 774 verify Hn+1(R) remain stateless 776 CCR: CIDs, CIDT(I), Hk+1(I), challenge(I), Hn+1(R), challenge(R), 777 HMAC_INIT, HMAC_CC, Ls(I) 778 --------------------------> 779 reconstruct the hash chain 780 verify HMAC_INIT and HMAC_CC 781 select CIDT(R) 782 CONF: CIDs, Hn+2(R), CIDT(R) 783 <-------------------------- 785 verify HMAC_CC 786 update host-pair context 788 Figure 11: Responder has lost its state 790 4.6 Re-addressing exchange 792 Once the state has been completed, both hosts have a host-pair 793 context. As a result, each host knows a locator set of its peer. It 794 is good to notice that the responder may be multi-homed, even the 795 initiator does not initially know all of the responder's locators. 796 The hosts use re-addressing exchange to dynamically update their 797 locator sets and to bootstrap hash chains. 799 The initiating party of the context establishment exchange was called 800 the initiator. Once the host-pair contexts are established, this 801 initial distinction is lost. Thus, the sender of the BOOTSTRAP 802 message is called the initiator of the re-addressing exchange. 804 Initiator Responder 806 construct new hash chain 808 BOOTSTRAP: CIDs, Ls(I), Hn(I), H0_new(I), challenge(I), 809 HMAC{Hn+1(I),(CIDs || Ls(I) || H0_new(I) || challenge(I))} 810 --------------------------> 811 Verify H1(I). 812 Generate a divided secret of Hk(R). 813 Send AC per locator to be verified. 815 AC1: CIDs, Key_count, Key_mask, key_piece, challenge(I) 816 ... <------------------------- 817 ACn <------------------------- 819 combine the key pieces 820 verify the combined key 822 ACR: CIDs, Key_combined, Key_mask, Hn+1(I) 823 --------------------------> 824 verify the combined key Hk(R) 825 verify HMAC 827 The re-addressing exchange is a three-way handshake. The BOOTSTRAP 828 message has two purposes. First, it informs the responder about the 829 currently active locator set. Second, it bootstraps a new hash 830 chain. 832 Once the responder receives a BOOTSTRAP message, it verifies that the 833 hash chain value, Hn(I), belongs to the initiator. In addition, the 834 responder stores the initiator's new anchor value, H0_new(I), into 835 the host-pair context. (Note: a host may verify locators after the 836 context establishment exchange by directly sending AC messages to the 837 peer). 839 The responder divides its next unused hash chain value, Hk(R), into 840 pieces using the secret splitting technique (See Section 3.4). The 841 responder MAY verify the locators in the locator set on demand basis 842 or all at once. In the latter case, the hash chain value is divided 843 into as many parts as the were locators in the received locator set. 844 The responder defines a key mask for each of the key pieces (see 845 Section 6.2.9). The key mask will later allow the responder to check 846 if all pieces reached the initiator. It is possible that the 847 initiator is not reachable via all of the locators in the locator 848 set. 850 The responder sends one address check message (AC) per locator that 851 it wants to verify. Each AC message contains one piece of the 852 divided Hk(R). The initiator should wait a while (TBD) for the 853 upcoming AC messages. The key count in every AC packet defines the 854 total amount of pieces, sent by the responder. 856 If the initiator receives all the pieces of the hash chain value, it 857 should verify that the combined pieces form a successor value of the 858 responder's hash chain. Otherwise, the initiator MAY stop the 859 re-addressing exchange. The initiator makes an OR-operation with all 860 of the received key masks and includes the result of the operation 861 with the combined key to the address check reply message (ACR). The 862 ACR message includes also hash chain value, Hn+1(I) that was used to 863 protect the HMAC. 865 The responder identifies the locators which were reachable, using the 866 combined key and the key mask. The responder authenticates also the 867 BOOTSTRAP message with hash chain value, Hn+1. Finally, the 868 responder marks the verified locators valid in the host-pair context. 870 5. Packets 872 There are eight basic WIMP-F packets. Four are for the context 873 establishment exchange, and three are for re-addressing, and one is 874 for re-synchronization. 876 Packets consist of the fixed header as described in Section 6.1, 877 followed by parameters. The parameter part, in turn, consists of 878 zero or more TLV coded parameters. 880 Packet representation uses the following operations: 882 () parameter 883 [] optional parameter 885 An upper layer payload MAY follow the WIMP-F header. The payload 886 proto field in the header indicates if there is additional data 887 following the WIMP-F header. 889 5.1 INIT - the context initiator packet 891 The WIMP-F header values for the INIT packet: 893 Header: 894 Packet Type = 1 895 SRC CID = Initiator's CID 896 DST CID = Responder's CID 898 IP( WIMP-F (CHALLENGE(I), HMAC-INIT, [CHALLENGE(R), HASVAL(R)])) 900 Valid control bits: P 902 5.2 CC - the context check packet 904 The WIMP-F header values for the CC packet: 906 Header: 907 Packet Type = 2 908 SRC CID = Responder's CID 909 DST CID = Initiator's CID 911 IP ( WIMP-F (CHALLENGE(R), HASVAL(R), LSET(R), HMAC-INIT, HMAC-CC )) 913 Valid control bits: P 915 The CIDs MUST be the same as received in INIT. 917 The responder copies the HMAC-INIT TLV from the INIT message to the 918 CC message. 920 5.3 CCR - the context check reply packet 922 The WIMP-F header values for the CCR packet: 924 Header: 925 Type = 3 926 SRC CID = Initiator's CID 927 DST CID = Responder's CID 929 IP ( WIMP-F ( HASHVAL(I), HASHVAL(R), CIDT(I), CHALLENGE(I), CHALLENGE(R), 930 LSET(I), HMAC-INIT, HMAC-CC)) 932 Valid control bits: P 934 The CIDs used MUST match the ones used in the INIT and CC messages. 936 The Initiator copies the HMAC-INIT, and HMAC-CC TLVs from the CC 937 message to the CCR message. 939 5.4 CONF - the context confirm packet 941 The WIMP-F header values for the CONF packet: 943 Header: 944 Packet Type = 4 945 SRC CID = Responder's CID 946 DST CID = Initiator's CID 948 IP ( WIMP-F ( HASHVAL(R), CIDT(R) )) 950 Valid control bits: P 952 The CIDs used MUST match the ones used in the CCR message. 954 5.5 BOOTSTRAP - The bootstrapping packet 956 The WIMP-F header values for the BOOTSTRAP packet: 958 Header: 959 Packet Type = 10 960 SRC CID = Initiator's CID 961 DST CID = Responder's CID 963 IP ( WIMP-F ( LSET(I), HASHVAL(I), ANCHOR(I), CHALLENGE(I), HMAC-BOOTSTRAP )) 965 Valid control bits: P 967 5.6 AC - The address check packet 969 The WIMP-F header values for the AC packet: 971 Header: 972 Packet Type = 11 973 SRC CID = Responder's CID 974 DST CID = Initiator's CID 976 IP ( WIMP-F ( KEY(R), CHALLENGE(I) )) 978 Valid control bits: P 980 The responder copies the CHALLENGE(I) from the BOOTSTRAP message to 981 the AC message(s) 983 5.7 ACR - The address check reply packet 985 The WIMP-F header values for the AC packet: 987 Header: 988 Packet Type = 20 989 SRC CID = Initiator's CID 990 DST CID = Responder's CID 992 IP ( WIMP-F ( KEY(I), HASHVAL(I) )) 994 Valid control bits: P 996 The KEY TLV is constructed of the received key pieces and their key 997 masks. 999 5.8 SYNC - The re-synchronization packet 1001 The WIMP-F header values for the SYNC packet: 1003 Header: 1004 Packet Type = 12 1005 SRC CID = Initiator's CID 1006 DST CID = Responder's CID 1008 IP ( WIMP-F ( CIDT(I), [CHALLENGE(I), HASHVAL(I)] )) 1010 Valid control bits: - 1012 6. Message formats 1014 6.1 Header format 1016 All WIMP-F packets start with a fixed header. 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Next Header | Payload Len | Type | VER. | RES. | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Controls | Checksum | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Sender's Identifier (CID) | 1026 | | 1027 | | 1028 | | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Receiver's Identifier (CID) | 1031 | | 1032 | | 1033 | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | | 1036 / WIMP-F Parameters / 1037 / / 1038 | | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 The WIMP-F header is carried in UDP payload followed by a next header 1042 that is defined in Next Header field. If no next headers follow, the 1043 decimal 59, IPPROTO_NONE, the IPV6 no next header value, is used. 1045 The Header Length field contains the length of the WIMP-F header and 1046 the length of parameters in 8 bytes units, excluding the first 8 1047 bytes. Since all WIMP-F headers MUST contain the sender's and 1048 receiver's CID fields, the minimum value for this field is 4, and 1049 conversely, the maximum length of the WIMP-F Parameters field is 1050 (255*8)-32 = 2008 bytes. 1052 The Packet Type indicates the WIMP-F packet type. The individual 1053 packet types are defined in the relevant sections. If a WIMP-F host 1054 receives a packet that contains an unknown packet type, it MUST drop 1055 the packet. 1057 The Version is four bits. The current version is 1. The version 1058 number is expected to be incremented only if there are incompatible 1059 changes to the protocol. Most extensions can be handled by defining 1060 new packet types, new parameter types, or new controls. 1062 The following four bits are reserved for future use. They MUST be 1063 zero when sent, and they SHOULD be ignored when handling a received 1064 packet. 1066 The CID fields are always 128 bits (16 bytes) long. 1068 6.1.1 WIMP-F Controls 1070 The WIMP-F control section transfers information about the structure 1071 of the packet and capabilities of the host. 1073 The following fields have been defined: 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | | | | | | | | | | | | |P| | | | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 P - Piggy backing The sending host is capable of sending and 1080 receiving additional data in WIMP-F packets. 1082 The rest of the fields are reserved for future use and MUST be set to 1083 zero on sent packets and ignored on received packets. 1085 6.1.2 Checksum 1087 If WIMP-F messages are sent in UDP datagrams the checksum field in 1088 the WIMP-F header is set to zero. 1090 If WIMP-F messages are implemented as IP extension headers, the 1091 checksum is calculated in the following way. The pseudo-header [1] 1092 contains the source and destination IPv6 addresses, WIMP-F packet 1093 length in the pseudo-header length field, a zero field, and the 1094 WIMP-F protocol number (TBD) in the Next Header field. The length 1095 field is in bytes and can be calculated from the WIMP-F header length 1096 field: (WIMP-F Header Length + 1) * 8. 1098 6.2 TLV format 1100 The TLV encoded parameters are described in the following 1101 subsections. The type-field value also describes the order of these 1102 fields in the packet. The parameters MUST be included into the 1103 packet so that the types form an increasing order. If the order does 1104 not follow this rule, the packet is considered to be malformed and it 1105 MUST be discarded. 1107 All the TLV parameters have a length which is a multiple of 8 bytes. 1108 When needed, padding MUST be added to the end of the parameter so 1109 that the total length becomes a multiple of 8 bytes. This rule 1110 ensures proper alignment of data. If padding is added, the Length 1111 field MUST NOT include the padding. Any added padding bytes MUST be 1112 set zero by the sender, but their content SHOULD NOT be checked on 1113 the receiving end. 1115 Consequently, the Length field indicates the length of the Contents 1116 field (in bytes). The total length of the TLV parameter (including 1117 Type, Length, Contents, and Padding) is related to the Length field 1118 according to the following formula: 1120 Total Length = 11 + Length - (Length + 3) % 8; 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Type |C| Length | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | | 1128 / Contents / 1129 / +-+-+-+-+-+-+-+-+ 1130 | | Padding | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Type Type code for the parameter 1134 C Critical. One if this parameter is critical, and 1135 MUST be recognized by the recipient, zero otherwise. 1136 The C bit is considered to be a part of the Type field. 1137 Consequently, critical parameters are always odd 1138 and non-critical ones have an even value. 1139 Length Length of the parameter, in bytes. 1140 Contents Parameter specific, defined by Type 1141 Padding Padding, 0-7 bytes, added if needed 1143 Critical parameters MUST be recognized by the recipient. If a 1144 recipient encounters a critical parameter that it does not recognize, 1145 it MUST NOT process the packet any further. 1147 Non-critical parameters MAY be safely ignored. If a recipient 1148 encounters a non-critical parameter that it does not recognize, it 1149 SHOULD proceed as if the parameter was not present in the received 1150 packet. 1152 6.2.1 HMAC-INIT 1154 0 1 2 3 1155 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 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Type | Length | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | | 1160 | HMAC | 1161 | | 1162 | | 1163 | | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Type 65500 1167 Length 20 1168 HMAC 1169 HMAC-SHA1 is computed over: 1170 - WIMP-F common header, 1171 - CIDT TLV, of the initiator, 1172 - LSET TLV, of the initiator 1173 - CHALLENGE TLV, of the initiator, 1175 excluding the HMAC-INIT TLV. The checksum field MUST 1176 be set to zero and the WIMP-F header length in the WIMP-F 1177 common header MUST be calculated to cover all the included 1178 parameters when the HMAC-SHA1 is calculated. The key is 1179 the first unrevealed hash value of the Initiator. 1181 HMAC-INIT calculation and verification process: 1183 INIT message sender: 1185 1. Create the INIT message, containing CIDT, LSET and CHALLENGE 1186 TLVs, without the HMAC-INIT TLV. 1188 2. Calculate the length field in the WIMP-F header. 1190 3. Compute the HMAC-SHA1. 1192 4. remove the CIDT and LSET TLVs. 1194 5. Add the HMAC-INIT TLV and optional TLVs to the packet. 1196 6. Recalculate the length field in the WIMP-F header. 1198 CCR message receiver: 1200 1. Create the INIT message, containing CIDT, LSET and CHALLENGE 1201 TLVs, without the HMAC-INIT TLV. 1203 2. Calculate the length in the WIMP-F header and clear the checksum 1204 field (set it to all zeros). 1206 3. Compute the HMAC-SHA1 and verify it against the received 1207 HMAC-INIT TLV. 1209 6.2.2 HMAC-CC 1211 The TLV structure is the same as in Section 6.2.1. The fields are: 1213 Type 65502 1214 Length 20 1215 HMAC 1216 HMAC-SHA1 is computed over: 1217 - WIMP-F common header. 1218 - HMAC-INIT TLV, received in the INIT message, 1219 - CHALLENGE TLV, of the responder, 1220 - LSET TLV, of the responder, 1222 excluding the HMAC-CC parameter. The checksum field MUST 1223 be set to zero and the WIMP-F header length in the WIMP-F 1224 common header MUST be calculated to cover all the included 1225 parameters when the SHA1 is calculated. The key is the 1226 the first unrevealed hash value of the responder. 1228 HMAC-CC calculation and verification process: 1230 CC message sender: 1232 1. Create the CC message, containing HMAC-INIT, CHALLENGE and LSET 1233 TLVs, without HMAC-CC TLV. 1235 2. Calculate the length field in the WIMP-F header. 1237 3. Compute the HMAC-SHA1. 1239 4. Add the HMAC-CC TLV and HASVAL TLV to the packet. 1241 5. Recalculate the length field in the WIMP-F header. 1243 CCR and CONF message receiver: 1245 1. Create the CC message, containing HMAC-INIT, CHALLENGE and LSET 1246 TLVs, without HMAC-CC and HASHVAL TLVs. 1248 2. Calculate the length field in the WIMP-F header and clear the 1249 checksum field (set it to all zeros). 1251 3. Compute the HMAC-SHA1 and verify it against the received HMAC-CC. 1253 6.2.3 HMAC-BOOTSTRAP 1255 The TLV structure is the same as in Section 6.2.1. The fields are: 1257 Type 65504 1258 Length 20 1259 HMAC 1260 HMAC-SHA1 is computed over: 1261 - WIMP-F common header, 1262 - LSET TLV, of the initiator, 1263 - ANCHOR TLV, of the initiator, 1264 - CHALLENGE TLV, of the initiator, 1266 excluding the HMAC-BOOTSTRAP parameter. The checksum 1267 field MUST be set to zero and the WIMP-F header length 1268 in the WIMP-F common header MUST be calculated to cover 1269 all the included parameters when the SHA1 is calculated. 1270 The key is the first unrevealed hash value of the initiator's 1271 hash chain. 1273 HMAC-BOOTSTRAP calculation and verification process. 1275 BOOTSTRAP message sender: 1277 1. Create the BOOTSTRAP message, containing LSET, ANCHOR, and 1278 CHALLENGE TLVs, without HMAC-BOOTSTRAP and HASHVAL TLVs. 1280 2. Calculate the length field in the WIMP-F header. 1282 3. Compute the HMAC-SHA1. 1284 4. Add the HMAC-CC and HASHVAL TLVs to the packet. 1286 5. Recalculate the length field in the WIMP-F header. 1288 ACR message receiver: 1290 1. Create the BOOTSTRAP message, containing LSET, ANCHOR, and 1291 CHALLENGE TLVs, without HMAC-BOOTSTRAP and HASHVAL TLVs. 1293 2. Calculate the length field in the WIMP-F header and clear the 1294 checksum field (set it to all zeros). 1296 3. Compute the HMAC-SHA1 and verify it against the received 1297 HMAC-BOOTSTRAP. 1299 6.2.4 HASHVAL 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Type | Length | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Chain ID | Count | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | reserved | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | | 1311 | | 1312 | Hash | 1313 | | 1314 | | 1315 | | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Type 12 1319 Length 28 1320 Chain ID Identifier of the Hash Chain. 1321 Count The number of a hash chain value in the hash chain. 1322 zero means an anchor value. 1323 Reserved Zero when sent, ignored when received 1324 Hash 160 bit SHA1 hash value. 1326 6.2.5 ANCHOR 1328 The TLV structure is the same as in Section 6.2.4. The fields are: 1330 Type 10 1331 Length 28 1332 Count 0 (an anchor value). 1333 Reserved Zero when sent, ignored when received 1334 Hash 160 bit SHA1 hash value. 1336 6.2.6 CIDT 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Type | Length | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Context ID | padding | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Type 16 1347 Length (variable) 1348 Context ID context identifier (e.g. flowid or SPI) 1350 6.2.7 CHALLENGE 1352 0 1 2 3 1353 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 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Type | Length | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Reserved | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Challenge | 1360 | | 1361 | | 1362 | | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 Type 20 1366 Length 20 1367 Reserved Zero when sent, ignored when received 1368 Challenge 128 bit (16 bytes) random number 1370 6.2.8 LSET 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Type | Length | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Reserved | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Locator #1 | 1380 / / 1381 | | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 / ... / 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Locator #n | 1386 / / 1387 | | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Type 22 1391 Length variable 1392 Reserved Zero when sent, ignored when received 1393 Locator IPv6 address (or IPv4 address in IPv6 format) 1395 6.2.9 KEY 1396 0 1 2 3 1397 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 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Type | Length | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Chain ID | Hash count | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | AC ID | Key Count | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Reserved | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Key mask | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Key piece 160 bit (AC message) / | 1410 / Combined key 160 bit (ACR message) / 1411 | | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Type 26 1415 Length 40 1416 Reserved Zero when sent, ignored when received 1417 Chain ID Identifier of the Hash Chain. 1418 Hash Count The number of a hash chain value in the responder's 1419 hash chain. The hash chain value that is divided into key 1420 pieces. 1421 AC ID An increasing counter that identifies the exchange with CIDs. 1422 Key count The total number of key pieces sent/received 1423 Key Mask 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 The responder defines a bit in the mask for a key piece. 1429 Key piece A hash chain value is divided into (160 bit) key pieces 1430 by the responder. 1431 Combined key The initiator constructs a combined key using the key 1432 pieces. 1434 The AC ID is related to a divided secret, i.e., a hash chain value. 1435 Every key piece related to that value must have the same AC ID. 1437 Responder sending AC message: 1439 The key count field value in the AC packet is the total number of key 1440 pieces sent by the responder, i.e. the total number of AC packets. 1441 Each KEY-MASK TLV in one AC packet contains a key piece having a 1442 corresponding bit on in the key mask field 1443 (Note: The responder is able to make a reachability test maximum for 1444 32 locators per divided key. However, it typically verifies the 1445 locators on demand basis.) 1447 Initiator sending ACR message: 1449 The initiator makes an OR -operation for all received key masks in 1450 the AC packets. The result of the operation is included in the 1451 KEY-MASK TLV in the ACR message.The key count field in KEY-MASK TLV 1452 in the ACR message indicates the number of key pieces the initiator 1453 received from the responder. The combined key is included into the 1454 KEY-MASK TLV. 1456 7. Packet processing 1458 7.1 Processing outgoing application data 1460 In an WIMP-F host, an application can send application level data 1461 using AIDs as source and destination identifiers. However, whenever 1462 there is such outgoing data, the stack has to send the resulting 1463 datagram using appropriate source and destination IP addresses. 1465 The following steps define the conceptual processing rules for 1466 outgoing datagrams destinated to a AID(R). 1468 1. If the datagram has a specified source AID(I), it MUST be one of 1469 the locators. 1471 2. If the datagram has an unspecified AID(I), the implementation 1472 MUST choose a suitable source AID(I) for the datagram. In 1473 selecting a proper AID(I), the implementation MUST consult the 1474 table of currently active WIMP-F sessions, and preferably select 1475 an AID(I) that already has an active session with the target 1476 AID(R). 1478 3. If there is no active WIMP-F session with the AID(R), one may be 1479 created by running the context establishment exchange. The INIT 1480 packet is sent to the AID(R). The host selects a CID(I) and 1481 optionally CID(R) for the context establishment exchange. At 1482 latest, the context must be established when the AID(I) differs 1483 from the selected source locator. 1485 4. Once there is an active WIMP session for the given AID(R), the 1486 AID(R) must match one of the locators in the context. The CIDs 1487 are represented by CIDTs in the IP payload packets. 1489 5. The AIDs in the datagram are replaced with suitable locators. 1491 7.2 Processing incoming application data 1493 Incoming WIMP-F datagrams arrive as normal IP packets containing 1494 CIDT. In the usual case the receiving host has a corresponding 1495 host-pair context, identified by the CIDT and a locator-pair in the 1496 packet. However, if the host has crashed or otherwise lost its 1497 state, it may not have such a host-pair context. 1499 The following steps define the conceptual processing rules for 1500 incoming datagrams targeted to a WIMP-F host-pair context. 1502 1. If the packet does not contains CIDT, it is sent to the upper 1503 layer without processing. 1505 2. If a proper host-pair context is detected, using the CIDT and 1506 locator-pair, the packet is processed by the wedge layer. If 1507 there are no host-pair context identified with the specific CIDT, 1508 the host MAY reply with a SYNC packet. 1510 3. If a proper host-pair context is found, the packet is processed 1511 by WIMP-F. The locators in the datagram are replaced with the 1512 AIDs associated with the host-pair context. 1514 8. State Machine 1516 Each host is assumed to have a separate WIMP-F implementation that 1517 manages the host-pair contexts and handles requests for new ones. 1518 Each host-pair context is governed by a state machine. WIMP-F 1519 implementation can simultaneously maintain host-pair contexts with 1520 more than one host. Furthermore, WIMP-F implementation may have more 1521 than one active host-pair context with another host; in this case, 1522 host-pair contexts are distinguished by their respective CIDs. It is 1523 not possible to have more than one host-pair contexts between any 1524 given pair of CIDs. Consequently, the only way for two hosts to have 1525 more than one parallel associations is to use different CIDs, at 1526 least in one end. 1528 The processing of packets depends on the state of the host-pair 1529 context(s) with respect to the originator of the packet. A WIMP-F 1530 implementation determines whether it has an active association with 1531 the originator of the packet based on the CIDs or the context 1532 identifier, CIDT, in the IP packet. 1534 The state machine is presented in a single system view, representing 1535 either an Initiator or a Responder. There is not a complete overlap 1536 of processing logic here and in the packet definitions. Both are 1537 needed to completely implement WIMP-F. 1539 Implementors must understand that the state machine, as described 1540 here, is informational. Specific implementations are free to 1541 implement the actual functions differently. 1543 States: 1545 START , state machine start 1547 INIT-sent , INIT sent by initiator 1549 CCR-sent , CCR sent by initiator 1551 ESTABLISHED , host-pair context established 1553 ESTABLISHED-BOOTSTRAP-sent , BOOTSTRAP sent 1555 ESTABLISHED-AC-sent , AC sent without receiving BOOTSTRAP message. 1557 FAILED , host-pair context establishment failed 1559 State Processes: 1561 +---------+ 1562 | START | 1563 +---------+ 1565 Context establishment request, send INIT and go to INIT-send 1566 Receive INIT, send CC and stay at START 1567 Receive CCR, process 1568 if successfull, send CONF and go to ESTABLISHED 1569 if fail, stay at START 1570 Receive IP packet without context, send SYNC and stay at START 1571 Receive ANYOTHER, drop and stay at START 1573 +-----------+ 1574 | INIT-sent | 1575 +-----------+ 1577 Receive INIT, send CC and stay at INIT-sent 1578 Receive CCR, process 1579 if successful, send CONF and go to ESTABLISHED 1580 if fail, stay at INIT-sent 1581 Receive CC, process 1582 if successful, send CCR and go to CCR-sent 1583 if fail, stay at INIT-sent 1584 Receive SYNC, process 1585 if successful, send INIT, and stay at INIT-sent 1586 if fail, change CID(I), send INIT, and stay at INIT-sent, or 1587 if fail, start another exchange supporting strong authentication, 1588 and stay at INIT-sent, or 1589 if fail, go to FAILED 1590 Receive ANYOTHER, drop and stay at INIT-sent 1591 Timeout, increment timeout counter 1592 If counter is less than INIT_RETRIES_MAX, send INIT, 1593 and stay at INIT-sent 1594 If counter is greater than INIT_RETRIES_MAX, go to FAILED 1596 +----------+ 1597 | CCR-sent | 1598 +----------+ 1600 Receive INIT, send CC and stay at CCR-sent 1601 Receive CCR, process 1602 if successful, send CONF and go to ESTABLISHED 1603 if fail, stay at CCR-SENT 1604 Receive CONF, process 1605 if successful, go to ESTABLISHED 1606 if fail, stay at CCR-SENT 1607 Receive ANYOTHER, drop and stay at CCR-sent 1608 Timeout, increment timeout counter 1609 If counter is less than CCR_RETRIES_MAX, send CCR and stay at CCR-sent 1610 If counter is greater than CCR_RETRIES_MAX, go to FAILED 1612 +-------------+ 1613 | ESTABLISHED | 1614 +-------------+ 1616 BOOTSTRAP to send, go to ESTABLISHED-BOOTSTRAP-sent 1617 AC to send, go to ESTABLISHED-AC-sent 1618 Receive BOOTSTRAP, process 1619 if successful, send AC(s), and stay at ESTABLISHED 1620 if fail, drop, and stay at ESTABLISHED 1621 Receive AC, process 1622 if successful, send ACR, and stay at ESTABLISHED 1623 if fail, drop and stay at ESTABLISHED 1624 Receive ACR, process 1625 if successful, update context, and stay at ESTABLISHED 1626 if fail, drop, and stay at ESTABLISHED 1627 Receive IP packet for context, process and stay at ESTABLISHED 1628 Receive SYNC, process 1629 if successful, send INIT, and stay at ESTABLISHED 1630 if fail, drop, and stay at ESTABLISHED 1631 Receive CC, process 1632 if successful, update context, send CCR, and stay at ESTABLISHED 1633 if fail, drop, and stay at ESTABLISHED 1634 Receive CONF, process 1635 if successful, update context, and stay at ESTABLISHED 1636 if fail, drop, and stay at ESTABLISHED 1637 Receive ANYOTHER, drop and stay at ESTABLISHED 1639 +-----------------------------+ 1640 | ESTABLISHED-BOOTSTRAP-sent | (for full re-addresing exchange) 1641 +-----------------------------+ 1642 Receive AC, process 1643 if successful, send ACR, and go to ESTABLISHED 1644 if fail, drop and cycle at ESTABLISHED-BOOTSTRAP-sent 1645 Receive BOOTSTRAP, process 1646 if successful, send AC(s), and stay at ESTABLISHED-BOOTSTRAP-sent 1647 if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent 1648 Receive ACR, process 1649 if successful, update context, and stay at 1650 ESTABLISHED-BOOTSTRAP-sent 1651 if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent 1652 Receive SYNC, process 1653 if successful, send INIT, and stay at ESTABLISHED-BOOTSTRAP-sent 1654 if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent 1655 Receive CC, process 1656 if successful, update context, send CCR, and go to ESTABLISHED 1657 if fail, drop, and stay at ESTABLISHED-BOOTSTRAP-sent 1658 Receive IP packet for context, process and stay at ESTABLISHED-BOOTSTRAP-sent 1659 Receive ANYOTHER, drop and stay at ESTABLISHED-BOOTSTRAP-sent 1660 Timeout, increment timeout counter 1661 If counter is less than BOOTSTRAP_RETRIES_MAX, 1662 send BOOTSTRAP to another locator, 1663 and stay at ESTABLISHED-BOOTSTRAP-sent 1664 If counter is greater than BOOTSTRAP_RETRIES_MAX, go to FAILED 1666 +----------------------+ 1667 | ESTABLISHED-AC-sent | (for dynamic AC-ACR reachability test) 1668 +----------------------+ 1669 Receive AC, process 1670 if successful, send ACR, and stay at ESTABLISHED-AC-sent 1671 if fail, drop and cycle at ESTABLISHED-AC-sent 1672 Receive BOOTSTRAP, process 1673 if successful, send AC, and stay at ESTABLISHED-AC-sent 1674 if fail, drop, and stay at ESTABLISHED-AC-sent 1675 Receive ACR, process 1676 if successful, update context, and go to ESTABLISHED 1677 if fail, drop, and stay at ESTABLISHED-AC-sent 1678 Receive SYNC, process 1679 if successful, send INIT, and stay at ESTABLISHED-AC-sent 1680 if fail, drop, and stay at ESTABLISHED-AC-sent 1681 Receive CC, process 1682 if successful, update context, send CCR, and go to ESTABLISHED 1683 if fail, drop, and stay at ESTABLISHED-AC-sent 1684 Receive IP packet for context, process and stay at ESTABLISHED-AC-sent 1685 Receive ANYOTHER, drop and stay at ESTABLISHED-AC-sent 1686 Timeout, increment timeout counter 1687 If counter is less than AC_RETRIES_MAX, send AC to another locator, 1688 and stay at ESTABLISHED-AC-sent 1689 If counter is greater than AC_RETRIES_MAX, go to FAILED 1691 9. Security Considerations 1693 The main objective in WIMP-F is to use one-way hash chains instead of 1694 public key cryptography. The reason for this is that there exists 1695 already a group of authenticated Diffie-Hellman key exchange 1696 protocols. Protocols using public key cryptography are often 1697 vulnerable for different kind of CPU related denial-of-service 1698 attacks. The trade-off between hash chain based message 1699 authentication and signatures is that the former is vulnerable for a 1700 class of man-in-the-middle attacks. However, if we accept that the 1701 first round-trip of the context establishment exchange is open for 1702 such attacks we obtain several advantages. The hash chain and HMAC 1703 computation are very lightweight operations compared to public key 1704 signing and signature verification. 1706 9.1 Context establishment exchange 1708 9.1.1 Man-in-the-Middle attacks 1710 The context establishment exchange is based on opportunistic 1711 authentication. In other words, both hosts, the initiator and the 1712 responder, blindly trust to each other during the first round-trip. 1713 The responder trusts that the INIT message comes from an authentic 1714 initiator. In a similar way, the initiator trusts that the CC 1715 message comes from an authentic responder. Thus, the first 1716 round-trip is vulnerable for the MitM attacks. 1718 Basically, the first round-trip of the exchange also bootstraps the 1719 hash chains. The initiator's anchor is sent in the third message, 1720 but the HMAC binds the first and the third messages together. A MitM 1721 attacker cannot later change any values in the CCR message, because 1722 the parameters are authenticated with the initiator's HMAC-INIT. 1723 Further, the HMAC-INIT is protected with the responder's HMAC-CC. In 1724 this way, the responder does not need to establish a state once it 1725 receives INIT message. 1727 An eavesdropper, listening INIT messages, cannot reserve a host-pair 1728 context by sending CCR message before the initiator, because the 1729 HMACs bind the messages together. Basically, the hash chains have 1730 two main purposes. They bind messages together, and they are used 1731 for authentication. The hash chain properties were discussed in more 1732 detail in Section 3. 1734 9.1.2 Denial-of-Service attacks 1736 The initiator may use any kind of identifier, CID(I), it wants with 1737 the responder, an ephemeral or a fixed identifier. The ephemeral 1738 identifier protects the initiator from a specific form of DoS attack. 1739 That is, an attacker cannot guess the initiator's identifier and 1740 reserve a state at the responder. If the initiator decides to use 1741 fixed identifiers it MAY need prove to the responder, using public 1742 key cryptography, that it owns the identifier. 1744 The beginning of the WIMP-F context establishment exchange is 1745 stateless for the responder, in order to avoid attacks where the 1746 attacker is trying to create inconsistent states at the responder. 1747 The responder makes a kind of reachability test before establishing a 1748 state with the initiator. The initiator has to prove that it is 1749 reachable at the location where it sent the initial packet. The 1750 responder MAY optionally restrict establishing a host-pair context 1751 with CID(I) if the responder already has several host-pair contexts 1752 related to the corresponding locator. This restrictions reduces the 1753 need of using any challenge puzzle (See HIP) in the CC message. 1755 The context establishment protocol is vulnerable for a context 1756 identifier, CIDT(R), related attack. The only parameter that is not 1757 protected with HMAC is the responder's CIDT in the last message. The 1758 reason for this is that the responder cannot reserve any values 1759 before it creates a state. The state is created after receiving the 1760 CCR message. As a result, the responder cannot include the CIDT into 1761 its HMAC in the CC message. a MitM attacker may change the 1762 responder's CIDT on the fly in the last message and course a 1763 denial-of-service situation. In other words, the responder will send 1764 IP packets with unrecognized context identifier to the initiator. 1765 However, the main objective of the protocol is to protect the hosts 1766 from the re-direction attacks and the presented attack does not open 1767 new vulnerabilities for that part of the protocol. 1769 9.1.3 Cryptanalysis based on the state loss procedure 1771 An attacker may apply the re-synchronization procedure to make 1772 cryptanalysis. The attacker may try to pump up a full hash chain of 1773 the responder. The attacker sends a storm of INIT packets, each of 1774 them containing different random challenge, CHALLENGE(R), and hash 1775 chain, HASHVAL(R), values. The destination identifier must match 1776 with the responder's identifier, but the initiator may freely select 1777 its own identifier. The responder drops the INIT packet, if the 1778 received hash value is not a member of the reconstructed hash chain. 1779 However, if the attacker manages to make a correct guess, the 1780 responder responds with CC packet containing the successor value of 1781 its hash chain. The attacker can send a new INIT message containing 1782 the received successor value and the challenge that was used to 1783 generate that hash chain. Finally, the attacker finds out the whole 1784 hash chain. 1786 The attacker must make the attack beforehand, because the responder 1787 does not reply with CC message, if it has already a context for the 1788 CIDs. In addition, the responder generates a fresh challenge for 1789 every new hash chain, and thus it is statistically hard to guess the 1790 correct combination that matches with the CIDs and the challenge. An 1791 ephemeral identifier of the initiator makes the attack more 1792 difficult. 1794 It may be possible that an attacker is able to make cryptanalysis 1795 about the responder's secret applying the previous attack. (The 1796 probability and difficultness of such an attack is TBD. Thus, the 1797 secret should be changed every TBD. If the attacker is able to find 1798 out the responder's secret, it may impersonate itself to a responder, 1799 and launch an attack by sending SYNC message to the initiator. The 1800 initiator sends the INIT packet to one of the responder's locators 1801 and verifies if the responder has rebooted. This attack requires 1802 that the attacker is able to listen the traffic between the inititor 1803 and the responder. Otherwise, the attacker cannot reply with the 1804 correct CC message, including the initiator's HMAC_INIT. A 1805 successful attack results in that the initiator updates its context 1806 with the attacker. (Note: It is still good to notice that WIMP-F is 1807 a semi-strong authentication protocol that does not require much 1808 computation power. If strong authentication is required some public 1809 key based protocol, should be used.) 1811 9.2 Re-addressing exchange 1813 A host must inform its peers about the new locator(s) after site 1814 renumbering. The sender of the new locator set is called the 1815 initiator. Once the responder receives BOOTSTRAP message it cannot 1816 trust the initiator is reachable at the new location(s). To avoid 1817 different kind of DoS and re-direction attacks the responder must 1818 verify that the initiator is indeed reachable at the claimed 1819 location(s). 1821 WIMP-F takes advantage of parallel paths between the hosts. The 1822 responder splits its hash chain value into pieces and includes one 1823 piece to each challenge (AC) message. The challenge messages are 1824 sent to different locators. As a result, an attacker has to locate 1825 at different topological locations, at the same time, to be able to 1826 answer to the challenge. The initiator, in turn, is able to verify 1827 that all of the pieces came from the authentic responder. The secret 1828 splitting works only if there are more than one destination locators 1829 and the messages are routed via different paths to the initiator. 1831 10. IANA Considerations 1833 TBD. 1835 11. Acknowledgments 1837 The initial version of this draft was written after a discussion 1838 between the authors, Pekka Nikander and Jari Arkko at the 58th IETF. 1839 The focus in this draft has been on authenticating the hosts to their 1840 peers with one-way hash chains. Instead of inventing the wheel once 1841 again, we took several ideas from the existing multi-homing protocol 1842 proposals. Thus, there are certain similarities, e.g., with NOID and 1843 HIP design factors. We would like to thank all contributers in those 1844 drafts who have affected the work. 1846 The authors would especially like to thank the following people who 1847 have given valuable feedback about WIMP (the names are in 1848 alphabetical order): Jari Arkko, Marcelo Bagnulo, Iljitsch van 1849 Beijnum, Gonzalo Camarillo, Brian E. Carpenter, Dave Crocker, Joel 1850 M. Halpern, Pekka Nikander, Ayyasamy Senthilkumar, and Margaret 1851 Wasserman. 1853 12. References 1855 12.1 Normative references 1857 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1858 Specification", RFC 2460, December 1998. 1860 12.2 Informative references 1862 [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1863 for Message Authentication", RFC 2104, February 1997. 1865 [3] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 1866 solutions", draft-nordmark-multi6-threats-00.txt (work in 1867 progress), October 2003. 1869 [4] Shamir, A., "How to Share a Secret", Comm. of the ACM 1870 22(11):612- 613, November 1979. 1872 [5] Blakely, G., "Safeguarding Cryptographic Keys", In Proc. AFIPS 1873 National Computer Conference pp. 313-317, 1979. 1875 [6] Canetti, R., Song, D. and D. Tygar, "Efficient Authentication 1876 and Signing of Multicast Streams over Lossy Channels", , May 1877 2000. 1879 [7] Lamport, L., "Password authentication with insecure 1880 communication", Commun. Mag. of ACM 24 (11), pp. 770-772, 1981. 1882 Authors' Addresses 1884 Jukka Ylitalo 1885 Ericsson Research Nomadiclab 1887 Jorvas FIN-02420 1888 FINLAND 1890 Phone: +358 9 299 1 1891 EMail: jukka.ylitalo@ericsson.com 1893 Vesa Torvinen 1894 Ericsson Research Nomadiclab 1896 Turku FIN-20520 1897 FINLAND 1899 Phone: +358 9 299 1 1900 EMail: vesa.torvinen@ericsson.com 1902 Erik Nordmark 1903 Sun Microsystems, Inc. 1904 17 Network Circle 1905 Mountain View, CA 1906 USA 1908 Phone: +1 650 786 2921 1909 EMail: erik.nordmark@sun.com 1911 Intellectual Property Statement 1913 The IETF takes no position regarding the validity or scope of any 1914 Intellectual Property Rights or other rights that might be claimed to 1915 pertain to the implementation or use of the technology described in 1916 this document or the extent to which any license under such rights 1917 might or might not be available; nor does it represent that it has 1918 made any independent effort to identify any such rights. Information 1919 on the procedures with respect to rights in RFC documents can be 1920 found in BCP 78 and BCP 79. 1922 Copies of IPR disclosures made to the IETF Secretariat and any 1923 assurances of licenses to be made available, or the result of an 1924 attempt made to obtain a general license or permission for the use of 1925 such proprietary rights by implementers or users of this 1926 specification can be obtained from the IETF on-line IPR repository at 1927 http://www.ietf.org/ipr. 1929 The IETF invites any interested party to bring to its attention any 1930 copyrights, patents or patent applications, or other proprietary 1931 rights that may cover technology that may be required to implement 1932 this standard. Please address the information to the IETF at 1933 ietf-ipr@ietf.org. 1935 Disclaimer of Validity 1937 This document and the information contained herein are provided on an 1938 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1939 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1940 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1941 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1942 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1945 Copyright Statement 1947 Copyright (C) The Internet Society (2004). This document is subject 1948 to the rights, licenses and restrictions contained in BCP 78, and 1949 except as set forth therein, the authors retain all their rights. 1951 Acknowledgment 1953 Funding for the RFC Editor function is currently provided by the 1954 Internet Society.