idnits 2.17.1 draft-moskowitz-hip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([16], [17], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. A spoofed I1 can result in an R1 attack on a system. An R1 sender MUST have a mechanism to rate limit R1s to an address. -- 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 (May 15, 2003) is 7623 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) == Missing Reference: '0' is mentioned on line 1797, but not defined == Unused Reference: '6' is defined on line 1597, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1604, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1610, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2408 (ref. '6') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2535 (ref. '8') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. '10') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2673 (ref. '11') (Obsoleted by RFC 6891) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '12') -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-12) exists of draft-ietf-ipseckey-rr-01 -- Possible downref: Non-RFC (?) normative reference: ref. '15' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 -- Possible downref: Normative reference to a draft: ref. '16' -- Unexpected draft version: The latest known version of draft-moskowitz-hip-impl is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '17' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft ICSAlabs, a Division of TruSecure 4 Expires: November 13, 2003 Corporation 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 May 15, 2003 9 Host Identity Protocol 10 draft-moskowitz-hip-06 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 13, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo specifies the details of the Host Identity Protocol (HIP). 41 The overall description of protocol and the underlying architectural 42 thinking is available in the HIP architecture [16] specification. 43 The Host Identity Protocol is used to establish a rapid 44 authentication between two hosts and to provide continuity of 45 communications between those hosts independent of the networking 46 layer. 48 The various forms of the Host Identity, HI, HIT, and LSI, are covered 49 in detail. It is described how they are used to support 50 authentication and the establishment of keying material, which is 51 then used by IPsec ESP [5] to establish a two-way secured 52 communication channel between the hosts. The basic state machine for 53 HIP provides a HIP compliant host with the resiliency to avoid many 54 DoS attacks. The basic HIP exchange for two public hosts shows the 55 actual packet flow. Other HIP exchanges, including those that work 56 across NATs are covered elsewhere, such as in the HIP implementation 57 document [17]. 59 Table of Contents 61 1. Status Warning . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1 A new name space and indentifiers . . . . . . . . . . . . . 5 64 2.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Conventions used in this document . . . . . . . . . . . . . 7 66 4. Host Identifiers . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 8 68 4.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . . . . 9 69 4.1.2 Storing HIT in DNS . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.3 Host Assigning Authority (HAA) field . . . . . . . . . . . . 10 71 4.2 Local Scope Identity (LSI) . . . . . . . . . . . . . . . . . 10 72 4.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . . 11 73 4.4 Difference between an LSI and the SPI . . . . . . . . . . . 12 74 5. The Host Identity Protocol . . . . . . . . . . . . . . . . . 13 75 5.1 Payload format . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.2 Base HIP exchange . . . . . . . . . . . . . . . . . . . . . 13 77 5.2.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . . 14 78 5.2.2 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . . 17 79 5.2.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.3 Piggypacking data on I2 and R2 . . . . . . . . . . . . . . . 18 81 5.4 Distributing certificates . . . . . . . . . . . . . . . . . 18 82 6. The Host Identity Protocol packet flow and state machine . . 19 83 6.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . . 20 85 6.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . . 20 86 6.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . . 21 87 6.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 6.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . . 21 89 6.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . . 23 90 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . . 24 91 7.1 I1 - the HIP Initiator packet . . . . . . . . . . . . . . . 24 92 7.2 R1 - the HIP Responder packet . . . . . . . . . . . . . . . 25 93 7.3 I2 - the HIP Second Initiator packet . . . . . . . . . . . . 26 94 7.4 R2 - the HIP Second Responder packet . . . . . . . . . . . . 27 95 7.5 NES - the HIP New SPI Packet . . . . . . . . . . . . . . . . 28 96 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . . 29 97 8. Packet processing . . . . . . . . . . . . . . . . . . . . . 30 98 8.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . . 30 99 8.2 Processing NES packets . . . . . . . . . . . . . . . . . . . 30 100 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . . 34 102 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . . 35 103 11.1 Security Association Management . . . . . . . . . . . . . . 35 104 11.2 Security Parameters Index (SPI) . . . . . . . . . . . . . . 35 105 11.3 Supported Transforms . . . . . . . . . . . . . . . . . . . . 35 106 11.4 Sequence Number . . . . . . . . . . . . . . . . . . . . . . 36 107 11.5 ESP usage with non-cryptographic HI . . . . . . . . . . . . 36 108 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 37 109 13. Security Considerations . . . . . . . . . . . . . . . . . . 38 110 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 111 15. ICANN Considerations . . . . . . . . . . . . . . . . . . . . 42 112 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 113 References . . . . . . . . . . . . . . . . . . . . . . . . . 44 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 115 A. Backwards compatibility API issues . . . . . . . . . . . . . 46 116 B. Probabilities of HIT collisions . . . . . . . . . . . . . . 47 117 C. Probabilities in the cookie calculation . . . . . . . . . . 48 118 D. Using responder cookies . . . . . . . . . . . . . . . . . . 49 119 Intellectual Property and Copyright Statements . . . . . . . 52 121 1. Status Warning 123 This document is an interim version of the to-be HIP protocol 124 specification including most but not necessarily all of the issues 125 discussed at the maling list and among the early implementors. 126 However, at the present stage this document contains a largish number 127 of open issues. Many of these issues are marked with XXX, or 128 enclosed in brackets, [like this], but not necessarily all. The 129 purpose of publishing this draft at this stage is to make it 130 available to the community outside of the group of early 131 implementors. Based on the current implementation experiences, it is 132 possible that there may be substantial changes to this specification 133 before it is completed. 135 The description of the REA packet has been removed from this 136 document, with the intention of publishing a separate draft on HIP 137 based mobility and multi-homing. 139 2. Introduction 141 The Host Identity Protocol (HIP) provides a rapid exchange of Host 142 Identities (HI) between two hosts. The exchange also establishes a 143 pair IPsec Security Associations (SA), to be used with IPsec ESP. 144 The HIP protocol is designed to be resistant to Denial-of-Service 145 (DoS) and Man-in-the-middle (MitM) attacks, and when used to enable 146 ESP, provides DoS and MitM protection to upper layer protocols, such 147 TCP and UDP. 149 2.1 A new name space and indentifiers 151 The Host Identity Protocol introduces a new namespace, the Host 152 Identity. The affects of this change are explained in the companion 153 document, the HIP architecture [16] specification. 155 There are three representations of the Host Identity, the full 156 Identifier (HI), the Host Identity Tag (HIT), and the Local Scope 157 Identity (LSI). Three representations are used, as each meets a 158 different design goal of HIP, and none of them can be removed and 159 meet these goals. The HI represents directly the Identity, normally 160 being a public key. Since there are different public key algorithms 161 that can be used with different key lengths, the HI is not good for 162 using as the HIP packet identifier, or as a index into the various 163 operational tables needed to support HIP. 165 A hash of the HI, the Host Identity Tag (HIT), thus becomes the 166 operational representation. It is 128 bits long. It is used in the 167 HIP payloads, and it is intended be used to index the corresponding 168 state in the end hosts. 170 In many environments, 128 bits is still considered large. For 171 example, currently used IPv4 based applications are constrained with 172 32 bit API fields. Thus, the third representation, the 32 bit LSI, 173 is needed. The LSI provides a compression of the HIT with only a 174 local scope so that it can be carried efficiently in any application 175 level packet and used in API calls. 177 2.2 The HIP protocol 179 The base HIP exchange consists of only four packets. The four-packet 180 design helps to make HIP DoS resilient. The protocol exchanges 181 Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the 182 parties in the 3rd and 4th packets. Additionally, it starts the 183 cookie exchange in the 2nd packet, completing it with the 3rd packet. 185 The exchange uses the Diffie-Hellman exchange to hide the Host 186 Identity of the Initiator in packet 3. The Responder's Host Identity 187 is not protected. It should be noted, however, that both the 188 Initiator and the Responder HITs are transported as such in the 189 packets, allowing an eavesdropper with a priori knowledge about the 190 parties to verify their identies. 192 Data packets start after the 4th packet. In some cases, the 3rd and 193 4th HIP packets can carry a data payload. However, the details of 194 that may need to be revised as more implementation experience is 195 gained. 197 Finally, HIP is designed as an end-to-end authentication and key 198 establishment protocol. It lacks much of the fine-grain policy 199 control found in IKE that allows IKE to support complex gateway 200 policies. Thus, HIP is not a complete replacement for IKE. In many 201 cases, particularly in spanning addressing realms, HIP would be the 202 preferred key establishment protocol. 204 3. Conventions used in this document 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC2119 [2]. 210 4. Host Identifiers 212 The structure of the Host Identifier is the public key of a public 213 key pair. Correspondingly, the Host Identity itself can be 214 considered to be the abstract entity that holds the private key from 215 the key pair. DSA is the MUST implement algorithm for all HIP 216 implementations, other algorithms MAY be supported. DSA was chosen 217 as the default algorithm due to its small signature size. 219 A Host Identity Tag (HIT) is used in protocols to represent the Host 220 Identity. Another representation of the Host Identity, the Local 221 Scope Identity (LSI), can also be used in protocols and APIs. LSI's 222 advantage over HIT is its size; its disadvantage is its local scope. 224 4.1 Host Identity Tag (HIT) 226 The Host Identity Tag is a 128 bit entity. There are two advantages 227 of using a hash over the actual Identity in protocols. First its fix 228 length makes for easier protocol coding and also better manages the 229 packet size cost of this technology. Secondly, it presents a 230 consistent format to the protocol whatever underlying identity 231 technology is used. 233 There are two types of HITs. HITs of the first type consist just of 234 the hash of the public key. HITs of the second type consist of a 235 Host Assigning Authority (HAA) field, and only the last 64 bits come 236 from a SHA-1 hash of the Host Identity. This latter format for HIT 237 is recommended for 'well known' systems. It is possible to support a 238 resolution mechanism for these names in directories like DNS. 239 Another use of HAA is in policy controls, see Section 12. 241 [XXX: Revise to define "pure" HITs and IPv6 compatible HITs.] The 242 formats of the HITs are designed to avoid the most commonly occurring 243 IPv6 addresses in RFC2373 [3]. Bits 0 and 1 are used to differentiate 244 the formats. If Bit 0 is zero and Bit 1 is one, then the rest of HIT 245 is a 126 bits of a SHA-1 hash of the Host Identity. If Bit 0 is one 246 and Bit 1 is zero, then the next 62 bits is the HAA field, and only 247 the last 64 bits come from the hash of the Host Identity. 249 Allocation Prefix Fraction of IPv6 250 (binary) Address Space 251 ------------------------ -------- ------------- 253 IPv6 Address space 00 1/4 254 126 bit HIT 01 1/4 255 HAA assigned 64 bit HIT 10 1/4 256 IPv6 Address space 11 1/4 258 4.1.1 Generating a HIT from a HI 260 The 126 or 64 hash bits in a HIT MUST be generated by taking the 261 least significant 126 or 64 bits of the SHA-1 [15] hash of the Host 262 Identity as it is represented in the Host Identity field in a HIP 263 payload packet. 265 For Identities that are DSA public keys, the HIT is formed as 266 follows. 268 1. The DSA public key is encoded as defined in RFC2536 [9] Section 269 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 270 length of the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T 271 octets long, where T is the size parameter as defined in RFC2536 272 [9]. The size parameter T, affecting the field lengths, MUST be 273 selected as the minimum value that is long enough to accomodate 274 P, G, and Y. The fields MUST be encoded in network byte order, 275 as defined in RFC2536 [9]. 277 2. A SHA-1 hash [15] is calculated over the encoded key. 279 3. The least signification 126 or 64 bits of the hash result are 280 used to create the HIT, as defined above. 282 The following pseudo-code illustrates the process. The symbol := 283 denotes assignment; the symbol += denotes appending. The 284 pseudo-function encode_in_network_byte_order takes two parameters, an 285 integer (bignum) and length, and returns the integer encoded into a 286 byte string of the given length. 288 buffer := encode_in_network_byte_order ( DSA.T , 1 ) 289 buffer += encode_in_network_byte_order ( DSA.Q , 20 ) 290 buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) 291 buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) 292 buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) 294 digest := SHA-1 ( buffer ) 296 hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) 297 hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) 299 4.1.2 Storing HIT in DNS 301 Any conforming implementation SHOULD be able to store Host 302 Identifiers in a DNS IPSECKEY RDATA [14] format. If a particular 303 form of a HI does not already have a specified RDATA format, a new 304 RDATA-like format SHOULD be defined for the HI. 306 During a transition period, instead of storing the HI, the HIT MAY be 307 stored in an AAAA RR. If a HIT is stored in an AAAA RR, it MUST be 308 returned as the last item in the set of AAAA RRs returned. 310 4.1.3 Host Assigning Authority (HAA) field 312 The 62 bits of HAA supports two levels of delegation. The first is a 313 registered assigning authority (RAA). The second is a registered 314 identity (RI, commonly a company). The RAA is 22 bits with values 315 assign sequentially by ICANN. The RI is 40 bits, also assigned 316 sequentially but by the RAA. This can be used to create a resolution 317 mechanism in the DNS. For example if FOO is RAA number 100 and BAR 318 is FOO's 50th registered identity, and if 1385D17FC63961F5 is the 319 hash of the Host Identity for www.foo.com, then by using DNS Binary 320 Labels [11] there could be a reverse lookup record like: 322 \[x1385D17FC63961F5/64].\[x32/40].\[x64/22].HIT.int IN PTR 323 www.foo.com. 325 (Note that RFC2673 [11] is Experimental, and that there are some bad 326 experiences with binary DNS labels. [12]) 328 4.2 Local Scope Identity (LSI) 330 LSIs are 32-bit localized representations of a Host Identity. The 331 purpose of an LSI is to facilitate using Host Identities in existing 332 IPv4 based protocols and APIs. The owner of the Host Identity does 333 not set its own LSI; each host selects its partner's 32 bit 334 representation for a Host Identity. LSI assignment is sequential off 335 of a random starting point. That is, at initialisation time, a 336 random starting point is selected for LSIs, and they are assigned 337 sequentially thereafter. This avoids collisions if LSIs are assigned 338 sequentially starting from zero, and even collisions on a busy host 339 if assigned randomly. 341 The LSIs SHOULD be allocated from the 1.0.0.0/8 subnet. That makes 342 it easier to differentiate between LSIs and IPv4 addresses at the API 343 level. If the LSI assigned by a peer to represent a host is 344 unccapteble, the host MAY terminate the HIP four-way handshake and 345 start anew. [XXX: The details probably need to be worked out.] 347 [XXX: There are still different opinions on how exactly to generate 348 LSIs. The proposed options include the following: 350 east 32 significant bits of HIT 352 a monotonically increasing number from a random seed 353 1.0.0.0/8 in the IPv4 private address space 355 When computing TCP and UDP checksums on sockets bound to LSIs, the 356 LSIs MUST be used in the place of the IPv4 addresses in the IPv4 357 pseudoheader. Other examples of how LSIs can be used include the 358 following: as the address in a FTP command and as the address in a 359 socket call. Thus, LSIs act as a bridge for Host Identity into old 360 protocols and APIs. 362 XXX: Recalculate the risk of a collision. The risk of collisions for 363 random assignment would be 1% in a population of 10,000, if all of 364 the IPv4 address space was used. 366 [XXX Question: Does the risk of collisions between LSIs really 367 matter? Since each host selects the representation of its peers, 368 there can't be collisions between the LSIs that are locally used to 369 represent the peers. On the other hand, the host itself is 370 represented by a number of LSIs, each selected separately by its 371 peers. To the IPv4 stack this might look like the host has a large 372 numer of local address aliases. 374 It looks like a collision becomes a problem if a new LSI, selected by 375 a new peer, happens to have a collision with some other LSI, already 376 locally selected to represent some other peer. In that case the host 377 cannot create a new IPv4 alias for the LSI, since it is already used 378 to represent a remote host. In that case the LSI must be rejected.] 380 4.3 Security Parameter Index (SPI) 382 SPIs are used in ESP to find the right security association for 383 received packets. The ESP SPIs have added significance when used 384 with HIP; they are a compressed representation of the HIT in every 385 packet. Thus they MAY be used by intermediary systems in providing 386 services like address mapping. Note that since the SPI has 387 significance at the receiver, only the < DST, SPI > uniquely 388 identifies the receiver HIT at every given point of time. The same 389 SPI value may be used by several hosts. The same < DST, SPI > may 390 denote different hosts at different points of time, depending on 391 which host is currently reachable at the DST. 393 Each host selects itself the SPI it wants to see in packets received 394 from its peer. This allows it to select different SPIs for different 395 peers. The SPI selection MUST be random. A different SPI MUST be 396 used for each HIP exchange with a particular host; this is to avoid a 397 replay attack. Additionally, when a host rekeys, the SPI MUST 398 change. Furthermore, if a host changes over to use a different IP 399 address, it MAY change the SPI used. One method for SPI creation 400 that meets these criteria, would be to concatenate the HIT with a 32 401 bit random or sequential number, hash this (using SHA1), and then use 402 the high order 32 bits as the SPI. 404 [XXX: It is not clear where the requirement for a random SPI comes 405 from. One possible reason is that the sequence numbers always start 406 at one, and therefore using the same SPI values soon again might 407 cause confusion? SPIs should be unique on incoming SAs, for 408 demultiplexing (unlike IPsec, cannot reuse SPI value over different 409 IP addresses).] 411 The selected SPI is communicated to the peer in the third (I2) and 412 fourth (R2) packets of the base HIP exchange. Changes in SPI are 413 signalled with NES or REA packets. 415 [Question: Do we really need separate NES and REA packets? Could 416 their functions be integrated? Partial answer: We do need the 417 version of NES that includes Diffie-Hellman. However, it looks like 418 the REAs need to be able to define new SPIs, too. Thus, the simple 419 case of using NES just to establish a new SPI from existing keymat is 420 probably not needed.] 422 4.4 Difference between an LSI and the SPI 424 There is a subtle difference between an LSI and a SPI. 426 The LSI is relatively longed lived. A system selects the LSI it 427 locally uses to represent its peer, it SHOULD reuse a previous LSI 428 for a HIT during a HIP exchange. This COULD be important in a 429 timeout recovery situation. The LSI ONLY appears in the 3rd and 4th 430 HIP packets (each system providing the other with its LSI). The LSI 431 is used anywhere in system processes where IP addresses have 432 traditionally have been used, like in TCBs and FTP port commands. 434 The SPI is short-lived. It changes with each HIP exchange and with a 435 HIP rekey and/or movement. A system notifies its peer of the SPI to 436 use in ESP packets sent to it. Since the SPI is in all but the first 437 two HIP packets, it can be used in intermediary systems to assist in 438 address remapping. 440 5. The Host Identity Protocol 442 The Host Identity Protocol is IP protocol TBD. The HIP payload could 443 be carried in every datagram. However, since HIP datagrams are 444 relatively large (at least 40 bytes), and ESP already has all of the 445 functionality to maintain and protect state, the HIP payload is 446 'compressed' into an ESP payload after the HIP exchange. Thus in 447 practice, HIP packets only occur in datagrams to establish or change 448 HIP state. 450 5.1 Payload format 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Next Header | Payload Len | Type | VER. | RES. | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Controls | CRC | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Sender's Host Identity Tag (HIT) | 460 | | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Receiver's Host Identity Tag (HIT) | 465 | | 466 | | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 / HIP Parameters / 471 / / 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 The exact contents of the HIP payload is defined in [13] 477 5.2 Base HIP exchange 479 The base HIP exchange serves to manage the establishment of state 480 between an Initiator and a Responder. The Initiator first sends a 481 trigger packet, I1, to the responder. The second packet, R1, starts 482 the actual exchange. In contains a puzzle, a cryptographic challenge 483 that the Initiator must solve before continuing the exchange. In its 484 reply, I2, the Initiator must display the solution. Without a 485 solution the I2 message is simply discarded. 487 The last three packets of the exchange, R1, I2, and R2, constitute a 488 standard authenticated Diffie-Hellman key exchange. The base 489 exchange is illustrated below. 491 Initiator Responder 493 I1: trigger exchange 494 --------------------------> 495 select pre-computed R1 496 R1: puzzle, D-H, sig 497 <------------------------- 498 check sig remain stateless 499 solve puzzle 500 I2: solution, D-H, sig 501 --------------------------> 502 compute D-H check cookie 503 check puzzle 504 check sig 505 R2: sig 506 <-------------------------- 507 check sig compute D-H 509 5.2.1 HIP Cookie Mechanism 511 The purpose of the HIP cookie mechanism is to protect the Responder 512 from a number of denial-of-service threats. It allows the Responder 513 to delay state creation until receiving I2. Furthermore, the puzzle 514 included in the cookie allows the Responder to use a fairly cheap 515 calculation to check that the Initiator is "sincere" in the sense 516 that it has churned CPU cycles in solving the puzzle. 518 The Cookie mechanism has been explicitly designed to give space for 519 various implementation options. It allows a responder implementation 520 to completely delay session specific state creation until a valid I2 521 is received. In such a case a validly formatted I2 can be rejected 522 earliest only once the responder has checked its validity by 523 computing one hash function. On the other hand, the design also 524 allows a responder implementation to keep state about received I1s, 525 and match the received I2s against the state, thereby allowing the 526 implementation to avoid the computational cost of the hash function. 527 The drawback of this latter approach is the requirement of creating 528 state. Finally, it also allows an implementation to use any 529 combination of the space-saving and computation-saving mechanism. 531 One possible way how a Responder can remain stateless but drop most 532 spoofed I2s is to base the selection of the cookie on some function 533 over the Initiator's identity. The idea is that the Responder has a 534 (perhaps varying) number of pre-calculated R1 packets, and it selects 535 one of these based on the information carried in I1. When the 536 Responder then later receives I2, it checks that the cookie in the I2 537 matches with the cookie send in the R1, thereby making it impractical 538 for the attacker to first exchange one I1/R1, and then generate a 539 large number of spoofed I2s that seemingly come from different IP 540 addresses or use different HITs. The method does not protect from an 541 attacker that uses fixed IP addresses and HITs, though. Against such 542 an attacker it is probably best to create a piece of local state, and 543 remember that the puzzle check has previously failed. See Appendix D 544 for one possible implementation. 546 The Responder can set the difficulty for Initiator, based on its 547 concern of trust of the Initiator. The Responder SHOULD use 548 heuristics to determine when it is under a denial-of-service attack, 549 and set the difficulty value K appropriately. 551 The Responder starts the cookie exchange when it receives an I1. The 552 Responder supplies a random number I, and requires the Initiator to 553 find a number J. To select a proper J, the Initator must create the 554 concatenation of I, the HITs of the parties, and J, and take a SHA-1 555 hash over this concatenation. The lowest order K bits of the result 556 MUST be zeros. To accomplish this, the Initiator will have to 557 generate a number of Js until one produces the hash target. The 558 Initiator SHOULD give up after trying 2^(K+2) times, and start over 559 the exchange. (See Appendix C.) The Responder needs to re-create 560 the contactenation of I, the HITs, and the provided J, and compute 561 the hash once to prove that the Initiator did its assigned task. 563 To prevent pre-computation attacks, the Responder MUST select I in 564 such a way that the Inititiator cannot guess it. Furthermore, the 565 construction MUST allow the Responder to verify that the value were 566 indeed selected by it and not by the Initiator. See Appendix D for 567 an example on how to implement this. 569 It is RECOMMENDED that the Responder generates a new cookie and a new 570 R1 once every few minutes. Furthermore, it is RECOMMENDED that the 571 responder remembers an old cookie at least 60 seconds after it has 572 been deprecated. These time values allow a slower Initiator to solve 573 the cookie puzzle while limiting the usability that an old, solved 574 cookie has to an attacker. 576 [XXX: A question is whether the R1 should include a timestamp so that 577 the Initator would not unnecessarily solve old, expired puzzles, 578 perhaps sent by an attacker?] 580 [XXX. Should we use Mike Burrow's memory bound functions instead of 581 SHA-1?] 583 In R1, the values I and K are sent in network byte order. Similarily, 584 in I2 the values I and J are sent in network byte order. The SHA-1 585 hash is created by concatenating, in network byte order, the 586 following data, in the following order: 588 64-bit random value I, in network byte order, as appearing in R1 589 and I2. 591 128-bit Initiator HIT, in network byte order, as appearing in the 592 HIP Payload in R1 and I2. 594 128-bit Responder HIT, in network byte order, as appearing in the 595 HIP Payload in R1 and I2. 597 64-bit random value J, in network byte order, as appearing in I2. 599 In order to be a valid response cookie, the K low-order bits of the 600 resulting SHA-1 digest must be zero. 602 Notes: 604 The length of the data to be hashed is 48 bytes. 606 All the data in the hash input MUST be in network byte order. 608 The order of the HITs depend on whether processing an R1 or I2. 609 Care must be taken to copy the values in right order to the hash 610 input. 612 Precomputation by the Responder Sets up the challenge difficulty K. 614 Generates a random number I. 615 Creates a signed R1 and caches it. 617 Responder Sends I and K in a HIP Cookie in an R1. 619 Saves I and K for a Delta time. 621 Initiator Generates repeated attempts to solve the challenge until a 622 matching J is found: 624 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 625 Send I and J in HIP Cookie in I2. 627 Responder Verify that the received I is a saved one. 629 Match the Response with a K based on I. 630 Compute V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) 631 Reject if V != 0 632 Accept if V == 0 634 5.2.2 HIP Controls 636 HIP controls are informative items that will influence the HIP 637 exchange and the use of ESP. HIP Controls are assigned a bit 638 location in the Controls field numbered left (MSB) to right (LSB). 639 Currently, there are two controls of value to a HIP exchange: 641 BIT Action 643 0 If value is 1, the HI is anonymous, i.e., generated for this 644 exchange only. Anonymous HIs SHOULD NOT be stored. This control 645 is set in packets R1 and/or I2. The peer receiving an anonymous HI 646 may choose to refuse it by silently dropping the exchange. 648 1 If value is 1, the ESP transform requires a 64 bit sequence 649 number. See Sequence Number section for processing this control. 651 2 If value is 1, the packet is followed by one or more CER packets. 652 The purpose is to inform the recipient to expect the CER packets, 653 allowing it to delay processing if needed. 655 Various controls will be defined over time. These controls will be 656 added to the end of the Controls field so that older implementations 657 can ignore them. 659 5.2.3 HIP Birthday 661 The Birthday is a reboot count used to manage state reestablishment 662 when one peer rebooted or timed out its SA. The Birthday is 663 increased every time the system boots. The Birthday also has to be 664 increased in accordance with the system's SA timeout parameter. If 665 the system has open SAs, it MUST increase its Birthday. This impacts 666 a system's approach to precomputing R1 packets. 668 Birthday SHOULD be a counter. It cannot be reset by the user and a 669 system is unlikely to need a birthday larger than 2^64. Date-time in 670 GMT can be used if a cross-boot counter is not possible, but it has a 671 potential problem if the system time is set back by the user. 673 5.3 Piggypacking data on I2 and R2 675 5.4 Distributing certificates 676 6. The Host Identity Protocol packet flow and state machine 678 [XXX: Revise if we use IPSECKEY.] A Host Identity Protocol exchange 679 SHOULD be initiated whenever the DNS lookup returns HIP KEY resource 680 records. Since some hosts may choose not to have information in DNS, 681 hosts MUST implement support opportunistic HIP [17]. At this point of 682 time, actually using opportunistic HIP is OPTIONAL. 684 A typical HIP packet flow is shown below. 686 I --> DNS (lookup R) 687 I <-- DNS (R's addresses, HI, and HIT) 688 I1 I --> R (Hi. Here is my I1, let's talk HIP) 689 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 690 I2 I --> R (Compute, compute, here is my counter I2) 691 R2 I <-- R (OK. Let's finish HIP with my R2) 692 I --> R (ESP protected data) 693 I <-- R (ESP protected data) 695 6.1 HIP Scenarios 697 The HIP protocol and state machine is designed to recover from one of 698 the parties crashing and losing its state. The following scenarios 699 describe the main use cases covered by the design. 701 No prior state between the two systems. 703 The system with data to send is the Initiator. The process 704 follows standard 4 packet exchange, establishing the SAs. 706 The system with data to send has no state with receiver, but 707 receiver has a residual SA. 709 Intiator acts as in no prior state, sending I1 and getting R1. 710 When Receiver gets I2, the old SA is 'discovered' and deleted; 711 the new SAs are established. 713 System with data to send has an SA, but receiver does not. 715 Receiver 'detects' when it receives an unknown SPI. Receiver 716 sends an R1 with a NULL Initiator HIT. Sender gets the R1 with 717 a later birthdate, discards old SA and continues exchange to 718 establish new SAs for sending data. 720 A peer determines that it needs to reset Sequence number or rekey. 722 It sends NES. Receiver sends NES response, establishes new SAs 723 for peers. 725 6.2 Refusing a HIP exchange 727 A HIP aware host may choose not to accept a HIP exchange. If the 728 host's policy is to only be an initiator, it should begin its own HIP 729 exchange. A host MAY choose to have such a policy since only the 730 Initiator HI is protected in the exchange. There is a risk of a race 731 condition if each host's policy is to only be an initiator, at which 732 point the HIP exchange will fail. 734 If the host's policy does not permit it to enter into a HIP exchange 735 with the Initiator, it should send an ICMP Protocol Unreachable, 736 Administratively Prohibited message. A more complex HIP packet is 737 not used here as it actually opens up more potential DoS attacks than 738 a simple ICMP message. 740 6.3 Reboot and SA timeout restart of HIP 742 Simulating a loss of state is a potential DoS attack. The following 743 process has been crafted to manage state recovery without presenting 744 a DoS opportunity. 746 If a host reboots or times out, it has lost its HIP state. If the 747 system that lost state has a datagram to deliver to its peer, it 748 simply restarts the HIP exchange. The peer sends an R1 HIP packet, 749 but does not reset its state until it receives the I2 HIP packet. 750 The I2 packet MUST have a Birthday greater than the current SA's 751 Birthday. This is to handle DoS attacks that simulate a reboot of a 752 peer. Note that either the original Initiator or the Responder could 753 end up restarting the exchange, becoming the new Initiator. An 754 example of the initial Responder needing to send a datagram but not 755 having state occurs when the SAs timed out and a server on the 756 Responder sends a keep-alive to the Initiator. 758 If a system receives an ESP packet for an unknown SPI, the assumption 759 is that it has lost the state and its peer did not. In this case, 760 the system treats the ESP packet like an I1 packet and sends an R1 761 packet. The Initiator HIT is typically NULL in the R1, since the 762 system usually does not know the peer's HIT any more. 764 The system receiving the R1 packet first checks to see if it has an 765 established and recently used SA with the party sending the R1. If 766 such an SA exists, the system checks the Birthday, if the Birthday is 767 greater than the current SA's Birthday, it processes the R1 packet 768 and resends the ESP packet along with or after the I2 packet. The 769 peer system processes the I2 in the normal manner, and replies with 770 an R2. This will reestablish state between the two peers. 771 [Potential DoS attack if hundreds of peers 'loose' their state and 772 all send R1 packets at once to a server. However, that would require 773 the attacker having specific knowledge about the SAs used, and an 774 ability to trigger R1s as the SAs are used.] 776 6.4 HIP State Machine 778 HIP has very little state. In the base HIP exchange, there is an 779 Initiator and a Responder. Once the SAs are established, this 780 distinction is lost. If the HIP state needs to be re-established, 781 the controlling parameters are which peer still has state and which 782 has a datagram to send to its peer. The following state machine 783 attempts to capture these processes. 785 The state machine is presented in a single system view, reresenting 786 either an Initiator or a Responder. There is not a complete overlap 787 of processing logic here and in the packet definitions. Both are 788 needed to completely implement HIP. 790 6.4.1 HIP States 792 E0 State machine start 794 E1 Initiating HIP 796 E2 Waiting to finish HIP 798 E3 HIP SA established 800 E-FAILED HIP SA establishment failed 802 6.4.2 HIP State Processes 804 +---------+ 805 | E0 | Start state 806 +---------+ 808 Datagram to send, send I1 and go to E1 809 Receive I1, send R1 and stay at E0 810 Receive I2, process 811 if successful, send R2 and go to E3 812 if fail, stay at E0 813 Receive ESP for unknown SA, send R1 and stay at E0 814 Receive ANYOTHER, drop and stay at E0 816 +---------+ 817 | E1 | Initiating HIP 818 +---------+ 820 Receive I1, send R1 and stay at E1 821 Receive I2, process 822 if successful, send R2 and go to E3 823 if fail, stay at E1 824 Receive R1, process 825 if successful, send I2 and go to E2 826 if fail, go to E-FAILED 827 Receive ANYOTHER, drop and stay at E1 828 Timeout, increment timeout counter 829 If counter is less than N1, send I1 and stay at E1 830 If counter is greater than N1, go to E-FAILED 832 +---------+ 833 | E2 | Waiting to finish HIP 834 +---------+ 836 Receive I1, send R1 and stay at E2 837 Receive I2, process 838 if successful, send R2 and go to E3 839 if fail, stay at E2 840 Receive R2, process 841 if successful, go to E3 842 if fail, go to E-FAILED 843 Receive ANYOTHER, drop and stay at E2 844 Timeout, increment timeout counter 845 If counter is less than N2, send I2 and stay at E2 846 If counter is greater than N2, go to E-FAILED 848 +---------+ 849 | E3 | HIP SA established 850 +---------+ 852 Receive I1, send R1 and stay at E3 853 Receive I2, process with Birthday check 854 if successful, send R2, drop old SA and cycle at E3 855 if fail, stay at E3 856 Receive R1, process with SA and Birthday check 857 if successful, send I2 with last datagram, drop old SA 858 and go to E2 859 if fail, stay at E3 860 Receive R2, drop and stay at E3 862 Receive ESP for SA, process and stay at E3 863 Receive NES, process 864 if successful, send NES and stay at E3 865 if failed, stay at E3 866 Receive REA, process and stay at E3 868 6.4.3 Simplified HIP State Diagram 870 Receive packets cause a move to new state 872 +---------+ 873 | E0 |>---+ 874 +---------+ | 875 | ^ | | 876 | | | Dgm to | 877 +-+ | send | 878 I1 | | (note: ESP- means ESP with unknown SPI) 879 ESP- | | 880 v | 881 +---------+ | 882 | E1 |>---|----------+ 883 +---------+ | | 884 | | | 885 | R1 | | 886 | |I2 |I2 887 v | | 888 +---------+ | | 889 | E2 |>---|----------|-----+ 890 | |<---|-----+ | | 891 +---------+ | | | | 892 | | | | | 893 | R2 | |R1 | |I2 894 | | | | | 895 v | | | | 896 +---------+<---+ | | | 897 | |----------+ | | 898 | E3 |<--------------+ | 899 | |<--------------------+ 900 +---------+ 901 | ^ 902 | | 903 +--+ 904 ESP, 905 NES, 906 REA, 907 I1, 908 I2 910 7. HIP Packets 912 There are 9 HIP packets. Four are for the base HIP exchange, four 913 are for mid-state changes (rekeying and address migration), and one 914 is a broadcast for use when there is no IP addressing (e.g., before 915 DHCP exchange). 917 Packet representation uses the following operations: 919 PPP() payload of type PPP 921 FFF\{contents\} function FFF applied on contents 923 [] optional payload 925 An ESP payload MAY follow some HIP payloads. This transmission 926 optimization SHOULD NOT be used if it results in fragmentation, and 927 there would not be any fragmentation if the ESP payload were sent by 928 itself. All implementations MUST be able to receive and process 929 piggybacked ESP payloads. 931 7.1 I1 - the HIP Initiator packet 933 Next Header = IPPROTO_NONE 934 Type = 1 935 SRC HIT = Initiator's HIT 936 DST HIT = Responder's HIT, or NULL 938 IP(HIP()) 940 The Initiator gets the Responder's HIT either from a DNS lookup of 941 the responder's FQDN or from a local table. If the initiator does 942 not know the responder's HIT, it may attempt anonymous mode by using 943 NULL (all zeros) as the responder's HIT. 945 Since this packet is so easy to spoof even if it were signed, no 946 attempt is made to add to its generation or processing cost. 948 Implementation MUST be able to handle a storm of reveived I1 packets, 949 discarding those with common content that arrive within a small time 950 delta. 952 7.2 R1 - the HIP Responder packet 954 Next Header = IPPROTO_NONE 955 Type = 2 956 SRC HIT = Responder's HIT 957 DST HIT = Initiator's HIT 959 Payload Contains: 960 Birthday and Cookie 961 Responder's Diffie-Hellman public value 962 HIP transform 963 ESP transform 964 Responder's HI 965 Signature 967 IP (HIP ( BIRTHDAY_COOKIE, 968 ( DIFFIE_HELLMAN_FULL | DIFFIE_HELLMAN ), 969 HIP_TRANSFORM, 970 ESP_TRANSFORM, 971 HOST_ID, 972 HIP_SIGNATURE ) ) 974 The R1 packet may be followed by one or more CER packets. In this 975 case, the C-bit in the control field MUST be set. 977 If the Responder has multiple HIs, the HIT used MUST match 978 Initiator's request. If the Initiator used anonymous mode, the 979 Responder may select freely among its HIs. 981 The Initiator HIT MUST match the one received in I1. If the R1 is a 982 response to an ESP packet with an unknown SPI, the Initiator HIT 983 SHOULD be zero. 985 The Birthday is a reboot count used to manage state reestablishment 986 when one peer rebooted or timed out its SA. 988 The Cookie contains random I and difficulty K. K is number of bits 989 that the Initiator must match get zero in the puzzle. 991 The Diffie-Hellman value is ephemeral, but can be reused over a 992 number of connections. In fact, as a defense against I1 storms, an 993 implementation MAY use the same Diffie-Hellman value for a period of 994 time, for example, 15 minutes. By using a small number of different 995 Cookies for a given Diffie-Hellman value, the R1 packets can be 996 pre-computed and delivered as quickly as I1 packets arrive. A 997 scavenger process should clean up unused DHs and Cookies. 999 The HIP_TRANSFORM contains the encryption algorithms supported by the 1000 responder to protect the HI exchange, in order of preference. All 1001 implementations MUST support the 3DES [7] transform. 1003 The ESP_TRANSFORM contains the ESP modes supported by the responder, 1004 in order of preference. All implementations MUST support 3DES [7] 1005 with HMAC-SHA-1-96 [4]. 1007 The SIG is calculated over the whole HIP envelope, after setting the 1008 Initiator HIT and header checksum temporarily to zero. This allows 1009 the Responder to use precomputed R1s. The Initiator SHOULD validate 1010 this SIG. It SHOULD check that the HI received matches with the one 1011 expected, if any. 1013 7.3 I2 - the HIP Second Initiator packet 1015 Next Header = IPPROTO_NONE or IPPROTO_ESP 1016 Type = 3 1017 SRC HIT = Initiator's HIT 1018 DST HIT = Responder's HIT 1019 Payload Contains: 1020 Responder's SPI and LSI 1021 Birthday and Cookie 1022 Initiator's Diffie-Hellman public value 1023 HIP TRANSFORM 1024 ESP TRANSFORM 1025 The following data are encrypted using the HIP Transform 1026 Initiator's HI 1027 Signature 1028 Optional data in an ESP envelope 1030 IP(HIP(SPI_LSI, 1031 BIRTHDAY_COOKIE, 1032 DIFFIE_HELLMAN, 1033 HIP_TRANSFORM, 1034 ESP_TRANSFORM, 1035 ENCRYPTED{HOST_ID}, 1036 HIP_SIGNATURE)[,ESP(data)]) 1038 The HITs used MUST match the ones used previously. 1040 The Birthday is a reboot count used to manage state reestablishment 1041 when one peer rebooted or timed out its SA. 1043 The Cookie contains I from R1 and the computed J. The low order K 1044 bits of the SHA-1(I | ... | J) MUST match be zero. 1046 The Diffie-Hellman value is ephemeral. If precomputed, a scavenger 1047 process should clean up unused DHs. 1049 The HIP_TRANSFORM contains the encryption used to protect the HI 1050 exchange selected by the initiator. All implementations MUST support 1051 the 3DES transform. 1053 The Initiator's HI is encrypted using the HIP_TRANSFORM. The keying 1054 material is derived from the Diffie-Hellman exchanged as defined in 1055 Section 9. 1057 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 1058 All implementations MUST support 3DES [7] with HMAC-SHA-1-96 [4]. 1060 The HIP SIG is calculated over whole HIP envelope. The Responder 1061 MUST validate this SIG. It MAY use either the HI in the packet or 1062 the HI acquired by some other means. 1064 The optional ESP payload contains the first user datagram that the 1065 Initiator is sending to the Responder. The SPI is set to the value 1066 TBD, as the real SPI value to be used is not known yet by the 1067 Initiator. When the Responder processes the HIP payload, it 1068 generates the SPI and replaces the value TBD with this SPI before 1069 passing the packet to ESP processing. The Sequence Number SHOULD be 1070 set to ONE, as this is the first datagram for this SA. 1072 [XXX: Should we keep this paragraph? This seems to be rather 1073 complicated, and at least I don't quite understand all the 1074 implications. --Pekka] If the ESP transform uses the ESP header for 1075 the IV, then special considerations for the ESP header might apply. 1076 For example, if the transform requires a random value in the header, 1077 expecting it to be the SPI, the Sequence Number can be a random 1078 number, and be reset to ONE by the Responder. The Responder would 1079 pass the Initiator supplied SPI and Sequence Number to the decryption 1080 routine. 1082 7.4 R2 - the HIP Second Responder packet 1084 Next Header = IPPROTO_NONE or IPPROTO_ESP 1085 Type = 4 1086 SRC HIT = Responder's HIT 1087 DST HIT = Initiator's HIT 1088 Payload Contains: 1089 Initiator's LSI and SPI 1090 Signature 1091 Optional data in an ESP envelope 1093 IP(HIP(SPI_LSI, 1094 HIP_SIGNATURE),[ESP(data)]) 1096 The signature is calculated over whole HIP envelope. The Initiator 1097 MUST validate this signature. 1099 The optional ESP payload contains the first user datagram that the 1100 Responder is sending to the Initiator. The SPI is the value that was 1101 received within I2. The Sequence Number MUST be set to ONE, as this 1102 is the first datagram for this SA. 1104 7.5 NES - the HIP New SPI Packet 1106 The HIP New SPI Packet serves three functions. First it provides the 1107 peer system with its new SPI. Next, it optionally provides a new 1108 Diffie-Hellman key to produce new keying material. Additionally, it 1109 provides any intermediate system with the mapping of the old SPI to 1110 the new. This is important to systems like NATs [17] that use SPIs 1111 to maintain address translation state. The new SPI Packet is a HIP 1112 packet with SPI and D-H in the HIP payload. The HIP packet contains 1113 the current ESP Sequence Number and SPI to provide DoS and replay 1114 protection. 1116 Next Header = IPPROTO_NONE 1117 Type = 5 1118 SRC HIT = Sender's HIT 1119 DST HIT = Recipients's HIT 1120 Payload Contains: 1121 Sender's ESP Sequence Number 1122 Sender's old SPI 1123 Sender's new SPI 1124 Optionally Sender's Diffie-Hellman public value 1125 Signature 1126 Optional data in an ESP envelope 1127 In reply packet only 1129 IP(HIP(NEW_SPI 1130 [,DIFFIE_HELLMAN], 1131 HIP_SIGNATURE), 1132 [ESP(data)]) 1134 During the life of an SA established by HIP, one of the hosts may 1135 need to reset the Sequence Number to one (to prevent wrapping) and 1136 rekey. The reason for rekeying might be an approaching sequence 1137 number wrap in ESP, or a local policy on use of a key. A new SPI or 1138 rekeying ends the current SAs and starts a new ones on both peers. 1139 Intermediate systems that use the SPI will have to inspect HIP 1140 packets for a HIP New SPI packet. The packet is signed for the 1141 benefit of the Intermediate systems. 1143 This packet has a potential DoS attack of a packet within the replay 1144 window and proper SPI, but a malformed signature. Implementations 1145 MUST recognize when they are under attack and manage the attack. If 1146 it is still receiving ESP packets with increasing Sequence Numbers, 1147 the NES packets are obviously attacks and can be ignored. 1149 Since intermediate systems may need the new SPI values, the contents 1150 of this packet cannot be encrypted. 1152 Intermediate systems that use the SPI will have to inspect ALL HIP 1153 packets for a NES packet. This is a potential DoS attack against the 1154 Intermediate system, as the signature processing may be relatively 1155 expensive. A further step against attack for the Intermediate 1156 systems is to implement ESP's replay protection of windowing the 1157 sequence number. This requires the intermediate system to track ALL 1158 ESP packets to follow the Sequence Number. 1160 7.6 BOS - the HIP Bootstrap Packet 1162 Next Header = IPPROTO_NONE 1163 Type = 7 1164 SRC HIT = Announcer's HIT 1165 DST HIT = NULL 1166 Payload Contains: 1167 Announcer's HI 1168 Signature 1170 IP(HIP(HOST_ID, 1171 HIP_SIGNATURE)) 1173 The BOS packet may be followed by a CER packet if the HI is signed. 1174 In this case, the C-bit in the control field MUST be set. 1176 In some situations, an initiator may not be able to learn of a 1177 responder's information from DNS or another repository. Some 1178 examples of this are DHCP and NetBios servers. Thus, a packet is 1179 needed to provide information that would otherwise be gleaned from a 1180 repository. This HIP packet is either self-signed in applications 1181 like SoHo, or from a trust anchor in large private or public 1182 deployments. This packet SHOULD be broadcasted periodically. 1184 The Optional CER packets over the Announcer's HI by a higher level 1185 authority known to the Initiator is an alternative method for the 1186 Initiator to trust the Announcer's HI (over DNSSEC or PKI). 1188 [XXX: Andrew suggested possibility of piggybacked data to create an 1189 authenticated UDP.] 1191 8. Packet processing 1193 [XXX: This section is currently in its very beginning. It needs much 1194 more text.] 1196 8.1 R1 Management 1198 All compliant implementations MUST produce R1 packets. An R1 packet 1199 MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1 1200 information MUST not be discarded until Delta S after T. Time S is 1201 the delay needed for the last I2 to arrive back to the responder. A 1202 spoofed I1 can result in an R1 attack on a system. An R1 sender MUST 1203 have a mechanism to rate limit R1s to an address. 1205 8.2 Processing NES packets 1207 The ESP Sequence Number and current SPI are included to provide 1208 replay protection for the receiving peer. The old SA MUST NOT be 1209 deleted until all ESP packets with a lower Sequence Number have been 1210 received and processed, or a reasonable time has elapsed (to account 1211 for lost packets). If the Sequence Number is the replay window is 1212 greater than the number in the NES packet, the NES packet MUST be 1213 ignored. If the SPI number does not match with an existing SPI 1214 number used, the NES packet must be ignored. 1216 The peer that initiates a New SPI exchange MUST include a Diffie- 1217 Hellmen key. Its peer MUST respond with a New SPI packet, an MAY 1218 include a Diffie-Hellman key if the receiving system's policy is to 1219 increase the new KEYMAT by changing its key pair. 1221 When a host receives a New SPI Packet with a Diffie-Hellman, its next 1222 ESP packet MUST use the KEYMAT generated by the new Kij. The sending 1223 host MUST expect at least a replay window worth of ESP packets using 1224 the old Kij. Out of order delivery could result in needing the old 1225 Kij after packets start arriving using the new SA's Kij. Once past 1226 the rekeying start, the sending host can drop the old SA and its Kij. 1228 The first packet sent by the receiving system MUST be a HIP New SPI 1229 packet. It MAY also include a datagram, using the new SAs. This 1230 packet supplies the new SPI for the rekeying system, which cannot 1231 send any packets until it receives this packet. If it does not 1232 receive a HIP New SPI packet within a reasonable round trip delta, it 1233 MUST assume it or the HIP Rekey packet was lost and MAY resend the 1234 HIP New SPI packet or renegotiate HIP as if in a reboot condition. 1235 The choice is a local policy decision. 1237 This packet MAY contain a Diffie-Hellman key, if the receiving 1238 system's policy is to increase the new KEYMAT by changing its key 1239 pair. 1241 9. HIP KEYMAT 1243 HIP keying material is derived from the Diffie-Hellman Kij produced 1244 during the base qHIP exchange. The initiator has Kij during the 1245 creation of the I2 packet, and the responder has Kij once it receives 1246 the I2 packet. This is why I2 can already contain encrypted 1247 information. 1249 The KEYMAT is derived by feeding Kij and the HITs into the following 1250 operation; the | operation denotes concatenation. 1252 KEYMAT = K1 | K2 | K3 | ... 1253 where 1255 K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) 1256 K2 = SHA-1( Kij | K1 | 0x02 ) 1257 K3 = SHA-1( Kij | K2 | 0x03 ) 1258 ... 1259 K255 = SHA-1( Kij | K254 | 0xff ) 1260 K256 = SHA-1( Kij | K255 | 0x00 ) 1261 etc. 1263 Sort(HIT-I | HIT-R) is defined as the numeric network byte order 1264 comparison of the HITs, with lower HIT preceding higher HIT, 1265 resulting in the concatenation of the HITs in the said order. The 1266 initial keys are drawn sequentially in the following order: 1268 HIP Initiator key 1270 HIP Responder key (currently unused) 1272 Initiator ESP key 1274 Initiator AUTH key 1276 Responder ESP key 1278 Responder AUTH key 1280 The number of bits drawn for a given algorithm is the "natural" size 1281 of the keys. For the manatory algorithms, the following sizes apply: 1283 3DES 192 bits 1285 SHA-1 160 bits 1286 NULL 0 bits 1288 Subsequent rekeys without Diffie-Hellman just requre drawing out more 1289 sets of ESP keys. In the situation where Kij is the result of a HIP 1290 rekey exchange with Diffie-Hellman, there is only the need from one 1291 set of ESP keys, without the HIP keys. These are then the only keys 1292 taken from the KEYMAT. 1294 10. HIP Fragmentation Support 1296 XXX: What shall we do with fragmentation support? Fragementation 1297 makes the protocol fragile and somewhat vulnerable to state space 1298 exhausting DoS attacks. 1300 A HIP implementation MUST support IP fragmentation/reassembly. HIP 1301 packets can get large, and may encounter low MTUs along their routed 1302 path. Since HIP does not provide a mechanism to use multiple IP 1303 datagrams for a single HIP packet, support of path MTU discovery does 1304 not bring any value to HIP. HIP aware NAT systems MUST perform any 1305 IP reassembly/fragmentation. 1307 11. ESP with HIP 1309 HIP sets up a Security Association (SA) to enable ESP in an end-to- 1310 end manner that can span addressing realms (i.e. across NATs). This 1311 is accomplished through the various informations that are exchanged 1312 within HIP. It is anticipated that since HIP is designed for host 1313 usage, that is not for gateways, that only ESP transport mode will be 1314 supported with HIP. The SA is not bound to an IP address; all 1315 internal control of the SA is by the HIT and LSI. Thus a host can 1316 easily change its address using Mobile IP, DHCP, PPP, or IPv6 1317 readdressing and still maintain the SA. And since the transports are 1318 bound to the SA (LSI), any active transport is also maintained. So 1319 real world conditions like loss of a PPP connection and its 1320 reestablishment or a mobile cell change will not require a HIP 1321 negotiation or disruption of transport services. 1323 Since HIP does not negotiate any lifetimes, all lifetimes are local 1324 policy. The only lifetimes a HIP implementation MUST support are 1325 sequence number rollover (for replay protection), and SA timeout. An 1326 SA times out if no packets are received using that SA. The default 1327 timeout value is 15 minutes. Implementations MAY support lifetimes 1328 for the various ESP transforms. Note that HIP does not offer any 1329 service comparable with IKE's Quick Mode. A Diffie- Hellman 1330 calculation is needed for each rekeying. 1332 11.1 Security Association Management 1334 An SA is indexed by the 2 SPIs and 2 HITs (both HITs since a system 1335 can have more than one HIT). An inactivity timer is recommended for 1336 all SAs. If the state dictates the deletion of an SA, a timer is set 1337 to allow for any late arriving packets. The SA MUST include the I 1338 that created it for replay detection. 1340 11.2 Security Parameters Index (SPI) 1342 The SPIs in ESP provide a simple compression of the HIP data from all 1343 packets after the HIP exchange. This does require a per HIT- pair 1344 Security Association (and SPI), and a decrease of policy granularity 1345 over other Key Management Protocols like IKE. 1347 When a host rekeys, it gets a new SPI from its partner. 1349 11.3 Supported Transforms 1351 All HIP implementations MUST support 3DES [7] and HMAC-SHA-1-96 [4]. 1352 If the Initiator does not support any of the transforms offered by 1353 the Responder in the R1 HIP packet, it MUST use 3DES and 1354 HMAC-SHA-1-96 and state so in the I2 HIP packet. 1356 In addition to 3DES, all implementations MUST implement the ESP NULL 1357 encryption and authentication algorithms. These algoritms are 1358 provided mainly for debugging purposes, and SHOULD NOT be used in 1359 production environments. The default configuration in 1360 implementations MUST be to reject NULL encryption or authentication. 1362 11.4 Sequence Number 1364 The Sequence Number field is MANDATORY in ESP. Anti-replay 1365 protection MUST be used in an ESP SA established with HIP. 1367 This means that each host MUST rekey before its sequence number 1368 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 1369 one Diffie-Hellman key can be changed, that of the rekeying host. 1370 However, if one host rekeys, the other host SHOULD rekey as well. 1372 In some instances, a 32 bit sequence number is inadequate. In either 1373 the I2 or R2 packets, a peer MAY require that a 64 bit sequence 1374 number be used. In this case the higher 32 bits are NOT included in 1375 the ESP header, but are simply kept local to both peers. 64 bit 1376 sequence numbers must only be used for ciphers that will not be open 1377 to cryptoanalysis as a result. AES is one such cipher. 1379 11.5 ESP usage with non-cryptographic HI 1381 [XXX: This section needs much more work, if we decide to keep this.] 1383 Even if the Host Identity is not cryptographically based, ESP MUST 1384 still be used after the HIP exchange between the two hosts. The HIP 1385 TRANSFORM in this case will be left out of the HIP exchange, and the 1386 ESP envelope will not have any authentication of encryption. The 1387 purpose of using ESP in this situation is to have the SPI (LSI) for 1388 associating the packets with the HITs, and the sequence # for replay 1389 protection. 1391 12. HIP Policies 1393 There are a number of variables that will influence the HIP exchanges 1394 that each host must support. All HIP implementations MUST support at 1395 least 2 HIs, one to publish in DNS and one for anonymous usage. 1396 Although anonymous HIs will be rarely used as responder HIs, they 1397 will be common for initiators. Support for multiple HIs is 1398 RECOMMENDED. 1400 Many initiators would want to use a different HI for different 1401 responders. The implementations SHOULD provide for an ACL of 1402 initiator HIT to responder HIT. This ACL SHOULD also include 1403 preferred transform and local lifetimes. For HITs with HAAs, 1404 wildcarding SHOULD be supported. Thus if a Community of Interest, 1405 like Banking, gets an RAA, a single ACL could be used. A global 1406 wildcard would represent the general policy to be used. Policy 1407 selection would be from most specific to most general. 1409 The value of K used in the HIP R1 packet can also vary by policy. K 1410 should never be greater than 20, but for trusted partners it could be 1411 as low as 0. 1413 Responders would need a similar ACL, representing which hosts they 1414 accept HIP exchanges, and the preferred transform and local 1415 lifetimes. Wildcarding SHOULD be support supported for this ACL 1416 also. 1418 13. Security Considerations 1420 HIP is designed to provide secure authentication of hosts and to 1421 provide a fast key exchange for IPsec ESP. HIP also attempts to 1422 limit the exposure of the host to various denial-of-service and man- 1423 in-the-middle attacks. In so doing, HIP itself is subject to its own 1424 DoS and MitM attacks that potentially could be more damaging to a 1425 host's ability to conduct business as usual. 1427 [XXX: Revise this based on the outcome of SPI usage.] The Security 1428 Association for ESP is indexed by the LSI-SPI, not the SPI and IP 1429 address. HIP enabled ESP is IP address independent. This might seem 1430 to make it easier for an attacker, but ESP with replay protection is 1431 already as well protected as possible, and the removal of the IP 1432 address as a check should not increase the exposure of ESP to DoS 1433 attacks. 1435 Denial-of-service attacks take advantage of the cost of start of 1436 state for a protocol on the responder compared to the 'cheapness' on 1437 the initiator. HIP makes no attempt to increase the cost of the 1438 start of state on the initiator, but makes an effort to reduce the 1439 cost to the responder. This is done by having the responder start 1440 the 3-way cookie exchange instead of the initiator, making the HIP 1441 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 1442 packet that the responder MAY use many times. The duration of use is 1443 a paranoia versus throughput concern. Using the same Diffie- Hellman 1444 values and random puzzle I has some risk. This risk needs to be 1445 balanced against a potential storm of HIP I1 packets. 1447 This shifting of the start of state cost to the initiator in creating 1448 the I2 HIP packet, presents another DoS attack. The attacker spoofs 1449 the I1 HIP packet and the responder sends out the R1 HIP packet. 1450 This could conceivably tie up the 'initiator' with evaluating the R1 1451 HIP packet, and creating the I2 HIP packet. The defense against this 1452 attack is to simply ignore any R1 packet where a corresponding I1 or 1453 ESP data was not sent. 1455 A second form of DoS attack arrives in the I2 HIP packet. Once the 1456 attacking initiator has solved the cookie challenge, it can send 1457 packets with spoofed IP source addresses with either invalid 1458 encrypted HIP payload component or a bad HIP SIG. This would take 1459 resources in the responder's part to reach the point to discover that 1460 the I2 packet cannot be completely processed. The defense against 1461 this attack is after N bad I2 packets, the responder would discard 1462 any I2s that contain the given I. Sort of a shutdown on the attack. 1463 The attacker would have to request another R1 and use that to launch 1464 a new attack. The responder could up the value of K while under 1465 attack. On the downside, valid I2s might get dropped too. 1467 A third form of DoS attack is emulating the restart of state after a 1468 reboot of one of the partners. To protect against such an attack, a 1469 system Birthday is included in the R1 and I2 packets to prove loss of 1470 state to a peer. The inclusion of the Birthday creates a very 1471 deterministic process for state restart. Any other action is a DoS 1472 attack. 1474 A fourth form of DoS attack is emulating the end of state. HIP has 1475 no end of state packet. It relies on a local policy timer to end 1476 state. 1478 Man-in-the-middle attacks are difficult to defend against, without 1479 third-party authentication. A skillful MitM could easily handle all 1480 parts of HIP; but HIP indirectly provides the following protection 1481 from a MitM attack. If the responder's HI is retrieved from a signed 1482 DNS zone by the initiator, the initiator can use this to validate the 1483 R1 HIP packet. 1485 Likewise, if the initiator's HI is in a secure DNS zone, the 1486 responder can retrieve it after it gets the I2 HIP packet and 1487 validate that. However, since an initiator may choose to use an 1488 anonymous HI, it knowingly risks a MitM attack. The responder may 1489 choose not to accept a HIP exchange with an anonymous initiator. 1491 New SPIs and rekeying provide another opportunity for an attacker. 1492 Replay protection is included to prevent a system from accepting an 1493 old new SPI packet. There is still the opening for an attacker to 1494 produce a packet with exactly the right Sequence Number and old SPI 1495 with a malformed signature, consuming considerable computing 1496 resources. All implementations must design to mitigate this attack. 1497 If ESP protected datagrams are still being received, there is an 1498 obvious attack. If the peer is quiet, it is easier for an attacker 1499 to launch this sort of attack, but again, the system should be able 1500 to recognize a regular influx of malformed signatures and take some 1501 action. 1503 There is a similar attack centered on the readdress packet. Similar 1504 defense mechanisms are appropriate here. 1506 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 1507 Unreachable' are to be expected and present a DoS attack. Against an 1508 Initiator, the attack would look like the responder does not support 1509 HIP, but shortly after receiving the ICMP message, the initiator 1510 would receive a valid R1 HIP packet. Thus to protect against this 1511 attack, an initiator should not react to an ICMP message until a 1512 reasonable delta time to get the real responder's R1 HIP packet. A 1513 similar attack against the responder is more involved. First an ICMP 1514 message is expected if the I1 was a DoS attack and the real owner of 1515 the spoofed IP address does not support HIP. The responder SHOULD 1516 NOT act on this ICMP message to remove the minimal state from the R1 1517 HIP packet (if it has one), but wait for either a valid I2 HIP packet 1518 or the natural timeout of the R1 HIP packet. This is to allow for a 1519 sophisticated attacker that is trying to break up the HIP exchange. 1520 Likewise, the initiator should ignore any ICMP message while waiting 1521 for an R2 HIP packet, deleting state only after a natural timeout. 1523 [XXX: This does not exist any more, does it?] Another MitM attack is 1524 simulating a Responder's rejection of a HIP initiation. This is a 1525 simple ICMP Host Unreachable, Administratively Prohibited message. A 1526 HIP packet was not used because it would either have to have unique 1527 content, and thus difficult to generate, resulting in yet another DoS 1528 attack, or just as spoofable as the ICMP message. The defense 1529 against this MitM attack is for the responder to wait a reasonable 1530 time period to get a valid R1 HIP packet. If one does not come, then 1531 the Initiator has to assume that the ICMP message is valid. Since 1532 this is the only point in the HIP exchange where this ICMP message is 1533 appropriate, it can be ignored at any other point in the exchange. 1535 14. IANA Considerations 1537 IANA has assigned IP Protocol number TBD to HIP. 1539 [XXX: Revise if we use IPSECKEY.] A new KEY RR protocol of XX is 1540 assigned to HIP and an algorithm of XX is assigned to HIT128. 1542 IANA will assign a SPI of TBD for use in the ESP header of the 1543 optional I2 HIP packet. 1545 15. ICANN Considerations 1547 ICANN will need to set up the HIT.int zone and accredit the 1548 registered assigning authorities (RAA) for HAA field. With 21 bits, 1549 ICANN can allocate just over 2M registries. 1551 16. Acknowledgments 1553 The drive to create HIP came to being after attending the MALLOC 1554 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave the 1555 original author, Bob Moskowitz, the assist to get HIP beyond 5 1556 paragraphs of ideas. It has matured considerably since the early 1557 drafts thanks to extensive input from IETFers. Most importantly, its 1558 design goals are articulated and are different from other efforts in 1559 this direction. Particular mention goes to the members of the 1560 NameSpace Research Group of the IRTF. Noel Chiappa provided the 1561 framework for LSIs and Kieth Moore the impetuous to provide 1562 resolvability. Steve Deering provided encouragement to keep working, 1563 as a solid proposal can act as a proof of ideas for a research group. 1565 Many others contributed; extensive security tips were provided by 1566 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 1567 Kocher taught the original authors, Bob Moskowitz, how to make the 1568 cookie exchange expensive for the Initiator to respond, but easy for 1569 the Responder to validate. Bill Sommerfeld supplied the Birthday 1570 concept to simplify reboot management. Rodney Thayer and Hugh 1571 Daniels provide extensive feedback. In the early times of this 1572 draft, John Gilmore kept Bob Moskowitz challenged to provide 1573 something of value. 1575 During the later stages of this document, when the editing baton was 1576 transfered to Pekka Nikander, the input from the early implementors 1577 were invaluable. Without having actual implementations, this 1578 document would not be on the level it is now. 1580 References 1582 [1] Mockapetris, P., "Domain names - implementation and 1583 specification", STD 13, RFC 1035, November 1987. 1585 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1586 Levels", BCP 14, RFC 2119, March 1997. 1588 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1589 Architecture", RFC 2373, July 1998. 1591 [4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 1592 and AH", RFC 2404, November 1998. 1594 [5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1595 (ESP)", RFC 2406, November 1998. 1597 [6] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 1598 Association and Key Management Protocol (ISAKMP)", RFC 2408, 1599 November 1998. 1601 [7] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 1602 RFC 2451, November 1998. 1604 [8] Eastlake, D., "Domain Name System Security Extensions", RFC 1605 2535, March 1999. 1607 [9] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 1608 (DNS)", RFC 2536, March 1999. 1610 [10] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1611 August 1999. 1613 [11] Crawford, M., "Binary Labels in the Domain Name System", RFC 1614 2673, August 1999. 1616 [12] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 1617 "Representing Internet Protocol version 6 (IPv6) Addresses in 1618 the Domain Name System (DNS)", RFC 3363, August 2002. 1620 [13] Jokela, P., "Optimized Packet Structure for HIP", 1621 draft-jokela-hip-packets-01 (work in progress), November 2002. 1623 [14] Richardson, M., "A method for storing IPsec keying material in 1624 DNS", draft-ietf-ipseckey-rr-01 (work in progress), April 2003. 1626 [15] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 1628 [16] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1629 Architecture", draft-moskowitz-hip-arch-03 (work in progress), 1630 May 2003. 1632 [17] Moskowitz, R., "Host Identity Payload Implementation", 1633 draft-moskowitz-hip-impl-02 (work in progress), January 2001. 1635 Authors' Addresses 1637 Robert Moskowitz 1638 ICSAlabs, a Division of TruSecure Corporation 1639 1000 Bent Creek Blvd, Suite 200 1640 Mechanicsburg, PA 1641 USA 1643 EMail: rgm@icsalabs.com 1645 Pekka Nikander 1646 Ericsson Research Nomadic Lab 1648 JORVAS FIN-02420 1649 FINLAND 1651 Phone: +358 9 299 1 1652 EMail: pekka.nikander@nomadiclab.com 1654 Appendix A. Backwards compatibility API issues 1656 Tom floated again the thought that that the LSI could be completely 1657 local and does not need to be exchanged, as long as each host can 1658 determine from local information what value for LSI that the peer 1659 will use in its checksum computations. Applications continue to use 1660 IP addresses in socket calls, and kernel does whatever NATting 1661 (including application NATting) is required. It was pointed out that 1662 this approach was going to be prone to some kinds of data flows 1663 escaping the HIP protection, unless the local housekeeping in an 1664 implementation was especially good. Example: FTP opens control 1665 connection to IP address. One or both parties move. FTP later opens 1666 data connection to the old IP address. Kernel must identify that the 1667 application really means to connect to the host that was previously 1668 at that IP address-- but obviously if the old address is reused by 1669 another host, this becomes difficult. 1671 Related to this, the discussion also opened up the question of DNS 1672 resolution. Should the HIT/LSI be returned to applications as a 1673 (spoofed) address in the resolution process, allowing apps to use the 1674 socket API with HIT or LSI values instead of an IP address? While 1675 this seems to be the original intention of LSIs, there are a couple 1676 of difficulties especially in the IPv4 case: 1678 how does kernel know whether value being passed in a socket call 1679 is an IP address or an LSI? The fact that a name resolver library 1680 gave an application an LSI is no guarantee that the application 1681 will use that information in its socket call. It may also have 1682 cached some IP address from before or received an IP address as 1683 side information. This difficulty may be relieved if LSIs are 1684 constrained to some well- known private subnet space. 1686 this may confuse legacy applications that assume that what is 1687 being passed to them is an IP address. Good examples of this are 1688 diagnostic tools such as dig and ping. 1690 what does kernel do with an LSI that it cannot map to an address 1691 based on information that it has locally cached? 1693 It seems that some modification to the resolver library (to 1694 explicitly convey HIP information rather than spoofing IP addresses), 1695 as well as modifications to socket API to explicitly let the kernel 1696 know that the application is HIP aware, are the cleanest long-term 1697 solution, but what to do about legacy applications??-- still an open 1698 issue. The HUT team has been considering these problems. 1700 Appendix B. Probabilities of HIT collisions 1702 The birthday paradox sets a bound for the expectation of collisions. 1703 It is based on the square root of the number of values. A 64-bit 1704 hash, then, would put the chances of a collision at 50-50 with 2^32 1705 hosts (4 billion). A 1% chance of collision would occur in a 1706 population of 640M and a .001% collision chance in a 20M population. 1707 A 128 bit hash will have the same .001% collision chance in a 9x10^16 1708 population. 1710 Appendix C. Probabilities in the cookie calculation 1712 A question: Is it quaranteed that the Initiator is able to solve the 1713 puzzle in this way when the K value is large? 1715 No, it is not guaranteed. But it is not guaranteed even in the old 1716 mechanism, since the Initiator may start far away from J and arrive 1717 to J after far too many steps. If we wanted to make sure that the 1718 Initiator finds a value, we would need to give some hint of a 1719 suitable J, and I don't think we want to do that. 1721 In general, if we model the hash function with a random function, the 1722 probability that one iteration gives are result with K zero bits is 1723 2^-K. Thus, the probablity that one iteration does *not* give K zero 1724 bits is (1 - 2^-K). Consequently, the probablity that 2^K iterations 1725 does not give K zero bits is (1 - 2^-K)^(2^K). 1727 Since my calculus starts to be rusty, I made a small experiment and 1728 found out that 1730 lim (1 - 2^-k)^(2^k) = 0.36788 1731 k->inf 1733 lim (1 - 2^-k)^(2^(k+1)) = 0.13534 1734 k->inf 1736 lim (1 - 2^-k)^(2^(k+2)) = 0.01832 1737 k->inf 1739 lim (1 - 2^-k)^(2^(k+3)) = 0.000335 1740 k->inf 1742 Thus, if hash functions were random functions, we would need about 1743 2^(K+3) iterations to make sure that the probability of a failure is 1744 less than 1% (actually less than 0.04%). Now, since my perhaps flawed 1745 understanding of hash functions is that they are "flatter" than 1746 random functions, 2^(K+3) is probably overkill. OTOH, the currently 1747 suggested 2^K is clearly too little. I'll change the draft to read 1748 2^(K+2). 1750 Appendix D. Using responder cookies 1752 As mentioned in Section 5.2.1, the responder may delay state creation 1753 and still reject most spoofed I2s by using a number of pre-calculated 1754 R1s and a local selection function. This appendix defines one 1755 possible implementation in detail. The purpose of this appendix is 1756 to give the implementators an idea on how to implement the mechanism. 1757 The method described in this appendix SHOULD NOT be used in any real 1758 implementation. If the implementation is based on this appendix, it 1759 SHOULD contain some local modification that makes an attacker's task 1760 harder. 1762 The basic idea is to create a cheap, varying local mapping function 1763 f: 1765 f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index 1767 That is, given the Initiators and Responders IP addresses and HITs, 1768 the function returns an index to a cookie. When processing an I1, 1769 the cookie is embedded in an pre-computed R1, and the Responder 1770 simply sends that particular R1 to the Initiator. When processing an 1771 I2, the cookie may still be embedded in the R1, or the R1 may be 1772 depracated (and replaced with a new one), but the cookie is still 1773 there. If the received cookie does not match with the R1 or saved 1774 cookie, the I2 is simply dropped. That prevents the Initiator from 1775 generating spoofed I2s with a probability that depends on the number 1776 of pre-computed R1s. 1778 As a concrete example, let us assume that the Responder has an array 1779 of R1s. Each slot in the array contains a timestamp, an R1, and an 1780 old cookie that was sent in the previous R1 that occupied that 1781 particular slot. The Responder replaces one R1 in the array every 1782 few minutes, thereby replacing all the R1s gradually. 1784 To create a varying mapping function, the Responder generates a 1785 random number every few minutes. The octets in the IP addresses and 1786 HITs are XORed together, and finally the result is XORed with the 1787 random number. Using pseudo-code, the function looks like the 1788 following. 1790 Pre-computation: 1791 r1 := random number 1793 Index computation: 1794 index := r1 XOR hit_r[0] XOR hit_r[1] XOR ... XOR hit_r[15] 1795 index := index XOR hit_i[0] XOR hit_i[1] XOR ... XOR hit_i[15] 1796 index := index XOR ip_r[0] XOR ip_r[1] XOR ... XOR ip_r[15] 1797 index := index XOR ip_i[0] XOR ip_i[1] XOR ... XOR ip_i[15] 1799 The index gives the slot used in the array. 1801 It is possible that an Initator receives an I1, and while it is 1802 computing I2, the Responder deprecates an R1 and/or chooses a new 1803 random number for the mapping function. Therefore the Responder must 1804 remember the cookies used in deprecated R1s and the previous random 1805 number. 1807 To check an received I2, the Responder can use a simple algorithm, 1808 expressed in pseudo-code as follows. 1810 If I2.hit_r does not match my_hits, drop the packet. 1812 index := compute_index(current_random_number, I2) 1813 If current_cookie[index] == I2.cookie, go to cookie check. 1814 If previous_cookei[index] == I2.cookie, go to cookie check. 1816 index := compute_index(previous_random_number, I2) 1817 If current_cookie[index] == I2.cookie, go to cookie check. 1818 If previous_cookei[index] == I2.cookie, go to cookie check. 1820 Drop packet. 1822 cookie_check: 1823 V := Ltrunc( SHA-1( I2.I, I2.hit_i, I2.hit_r, I2.J ), K ) 1824 if V != 0, drop the packet. 1826 Whenever the Responder receives an I2 that fails on the index check, 1827 it can simply drop the packet on the floor and forget about it. New 1828 I2s with the same or other spoofed parameters will get dropped with a 1829 reasonable probability and minimal effort. 1831 If a Responder receives an I2 that passes the index check but fails 1832 on the puzzle check, it should create a state indicating this. After 1833 two or three failures the Responder should cease checking the puzzle 1834 but drop the packets directly. This saves the Responder from the 1835 SHA-1 calculations. Such block should not last long, however, or 1836 there would be a danger that a legitimite Initiator could be blocked 1837 from getting connections. 1839 A key for the success of the defined scheme is that the mapping 1840 function must be considerably cheaper than computing SHA-1. It also 1841 must detect any changes in the IP addresses, and preferably most 1842 changes in the HITs. Checking the HITs is not that essential, 1843 though, since HITs are included in the cookie computation, too. 1845 The effectivity of the method can be varied by varying the size of 1846 the array containing pre-computed R1s. If the array is large, the 1847 probability that an I2 with a spoofed IP address or HIT happens to 1848 map to the same slot is fairly slow. However, a large array means 1849 that each R1 has a fairly long life time, thereby allowing an 1850 attacker to utilize one solved puzzle for a longer time. 1852 Intellectual Property Statement 1854 The IETF takes no position regarding the validity or scope of any 1855 intellectual property or other rights that might be claimed to 1856 pertain to the implementation or use of the technology described in 1857 this document or the extent to which any license under such rights 1858 might or might not be available; neither does it represent that it 1859 has made any effort to identify any such rights. Information on the 1860 IETF's procedures with respect to rights in standards-track and 1861 standards-related documentation can be found in BCP-11. Copies of 1862 claims of rights made available for publication and any assurances of 1863 licenses to be made available, or the result of an attempt made to 1864 obtain a general license or permission for the use of such 1865 proprietary rights by implementors or users of this specification can 1866 be obtained from the IETF Secretariat. 1868 The IETF invites any interested party to bring to its attention any 1869 copyrights, patents or patent applications, or other proprietary 1870 rights which may cover technology that may be required to practice 1871 this standard. Please address the information to the IETF Executive 1872 Director. 1874 Full Copyright Statement 1876 Copyright (C) The Internet Society (2003). All Rights Reserved. 1878 This document and translations of it may be copied and furnished to 1879 others, and derivative works that comment on or otherwise explain it 1880 or assist in its implementation may be prepared, copied, published 1881 and distributed, in whole or in part, without restriction of any 1882 kind, provided that the above copyright notice and this paragraph are 1883 included on all such copies and derivative works. However, this 1884 document itself may not be modified in any way, such as by removing 1885 the copyright notice or references to the Internet Society or other 1886 Internet organizations, except as needed for the purpose of 1887 developing Internet standards in which case the procedures for 1888 copyrights defined in the Internet Standards process must be 1889 followed, or as required to translate it into languages other than 1890 English. 1892 The limited permissions granted above are perpetual and will not be 1893 revoked by the Internet Society or its successors or assignees. 1895 This document and the information contained herein is provided on an 1896 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1897 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1898 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1899 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1900 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1902 Acknowledgement 1904 Funding for the RFC Editor function is currently provided by the 1905 Internet Society.