idnits 2.17.1 draft-moskowitz-hip-05.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 2) being 59 lines 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 ([HIPARCH], [HIPIMPL], [ESP]), 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (November 2001) is 8197 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: 'RFC2372' is mentioned on line 197, but not defined == Missing Reference: 'DNSBIN' is mentioned on line 249, but not defined == Unused Reference: 'RFC2373' is defined on line 1624, but no explicit reference was found in the text -- No information found for draft-ietf-moskowitz-hip-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIPARCH' -- No information found for draft-ietf-moskowitz-hip-impl - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIPIMPL' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. 'EDNS') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP-REGISTRY' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Moskowitz, TruSecure Corp. 2 Document: November 2001 4 Host Identity Payload 5 And Protocol 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Table of Contents 30 1. Abstract...........................................................2 31 2. Conventions used in this document..................................2 32 3. Introduction.......................................................3 33 4.1. Host Identity....................................................3 34 4.2. Host Identity Tag (HIT)..........................................4 35 4.2.1. Storing HIT in DNS.............................................5 36 4.3. Host Assigning Authority (HAA) field.............................5 37 4.4. Local Scope Identity (LSI).......................................5 38 4.5. Security Parameter Index (SPI)...................................6 39 4.6. Difference between an LSI and the SPI............................6 40 5. The Host Identity Payload..........................................6 41 5.1. HIP format.......................................................7 42 5.2. HIP Key Payload..................................................7 43 5.3. HIP Cookie Exchange..............................................8 44 5.3.1. HIP Cookie Mechanism...........................................9 45 5.3.2. HIP Controls...................................................9 46 5.3.3. HIP Birthday...................................................9 47 6. HIP Packets.......................................................10 48 6.1. I1 - the HIP Initiator packet...................................10 49 6.2. R1 - the HIP Responder packet...................................11 50 6.2.1. R1 Management.................................................12 51 6.3. I2 - the HIP Second Initiator packet............................12 53 Moskowitz 1 54 Host Identity Payload November 2001 56 6.4. R2 - the HIP Second Responder packet............................13 57 6.5. NES - the HIP New SPI Packet....................................14 58 6.6. REA - the HIP Readdress Packet..................................15 59 6.7. BOS - the HIP Bootstrap Packet..................................17 60 6.8. HIP Fragmentation Support.......................................17 61 7. ESP with HIP......................................................18 62 7.1. Security Association Management.................................18 63 7.2. Security Parameters Index (SPI).................................18 64 7.3. Supported Transforms............................................18 65 7.4. Sequence Number.................................................19 66 7.5. ESP usage with non-cryptographic HI.............................19 67 8. The Host Layer Protocol (HLP) packet flow.........................19 68 8.1. The Host Layer Protocol (HLP)...................................19 69 8.2. HLP Scenarios...................................................20 70 8.3. HIP KEYMAT......................................................20 71 8.4. Refusing a HLP exchange.........................................21 72 8.5. Reboot and SA timeout restart of HIP............................21 73 8.5. HLP State Machine...............................................22 74 8.5.1. HLP States....................................................22 75 8.5.2. HLP State Processes...........................................22 76 8.5.3. Simplified HLP State Diagram..................................23 77 9. HLP Policies......................................................24 78 10. Security Considerations..........................................24 79 11. IANA Considerations..............................................27 80 12. ICANN Considerations.............................................27 81 APPENDIX A. Security Transform Formats..............................27 82 APPENDIX B. Proposed change to the HIP Formats......................28 83 13. References.......................................................30 84 14. Acknowledgments..................................................31 85 15. Author's Address.................................................31 86 16. Copyright Statement..............................................32 88 1. Abstract 90 This memo describes the Host Identity Payload (HIP) described in the 91 HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that 92 uses it to establish a rapid authentication between two hosts and 93 continuity between those hosts independent of the Networking Layer. 94 The various forms of the Host Identity, HI, HIT, and LSI are covered 95 in detail and how they support the authentication and the 96 establishment of Keying Material that is used by ESP [ESP]. 98 The basic state machine for HIP provides a HIP compliant host with 99 the resiliency to avoid many DOS attacks. The basic HIP exchange 100 for two public hosts shows the actual packet flow. Other HIP 101 exchanges, including those that work across NATs are covered in the 102 HIP implementation document [HIPIMPL]. 104 2. Conventions used in this document 106 Moskowitz 2 107 Host Identity Payload November 2001 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in [RFC-2119]. 113 3. Introduction 115 The Host Identity Payload (HIP) along with the HIP Protocol provides 116 a rapid exchange of Host Identities (HI) that also establishes a 117 Security Association for ESP. The HIP protocol is resistant to 118 Denial-of-Service (DOS) and Man-in-the-middle (MITM) attacks, and 119 when used to enable ESP, provides DOS and MITM protection to TCP and 120 UDP. 122 The Host Identity Payload introduces a new namespace, the Host 123 Identity. There are three representations of the Host Identity, 124 the full Identity (HI), the Host Identity Tag (HIT), and the Local 125 Scope Identity (LSI). Three representations are used, as each meets 126 a different design goal of HIP, and none of them can be removed and 127 meet these goals. The HI is the Identity, normally a public key. 128 Since there are different public key algorithms that can be used 129 with different key lengths, the HI is not good for using as the HIP 130 packet identifier, or as a index into the various operational tables 131 needed to support HIP. 133 A hash of the HI, the Host Identity Tag (HIT) thus becomes the 134 operational representation. It is 128 bits long, and the index in 135 the payload. However, in many environments, 128 bits is still 136 considered large. Also IPv4 is constrained with 32 bit API fields. 137 So the third representation, the LSI is 32 bits. The LSI provides a 138 compression of the HIT with only a local scope so that it can be 139 carried efficiently in any packet and used in API calls. 141 The HIP protocol is only four packets. The four-packet design helps 142 make HIP DOS attack resilient. The protocol exchanges Diffie-Hellman 143 keys in the 2nd and 3rd packets and starts the cookie exchange in 144 the 2nd packet. The exchange uses the Diffie-Hellman exchange to 145 hide the Host Identity of the Initiator in packet 3. The 146 Responder's Host Identity is not encrypted in packet 2, so it is not 147 included in the encrypted part of packet 4. Data datagrams start 148 after the 4th packet. However, in some cases, the 3rd and 4th HIP 149 packets can carry a datagram. 151 Finally, HIP is designed as an end-to-end authentication and key 152 establishment protocol. It lacks much of the fine-grain policy 153 control found in IKE that allows IKE to support complex gateway 154 policies. Thus HIP is not a complete replacement for IKE. In many 155 cases, particularly in spanning addressing realms, HIP would be the 156 preferred key establishment protocol. 158 4.1. Host Identity 160 Moskowitz 3 161 Host Identity Payload November 2001 163 The structure of the Host Identity is that of a public key pair. 164 DSA is the MUST implement algorithm for any implementation 165 supporting public keys for the Host Identity. DSA was chosen as the 166 default algorithm due to its small signature size. 168 The Host Identity is never directly used in any Internet protocol. 169 It may be stored in various DNS or LDAP directories as identified in 170 the HIP architecture and it is passed in HIP. It SHOULD be stored 171 in a DNS KEY RR with the protocol set to HIP. A Host Identity Tag 172 (HIT) is used in protocols to represent the Host Identity. Another 173 representation of the Host Identity, the Local Scope Identity (LSI) 174 can also be used in protocols and APIs. LSI's advantage over HIT is 175 its size; its disadvantage is its local scope. 177 4.2. Host Identity Tag (HIT) 179 The Host Identity Tag is a 128 bit field. There are two advantages 180 of using a hash over the actual Identity in protocols. First its 181 fix length makes for easier protocol coding and also better manages 182 the packet size cost of this technology. Secondly, it presents a 183 consistent format to the protocol whatever underlying identity 184 technology is used. 186 HIT functions much like the SPI does in IPsec. However, instead of 187 being an arbitrary 32-bit value that, in combination with the 188 destination IP address and security protocol (ESP), uniquely 189 identifies the Security Association for a datagram, HIT identifies 190 the public key that can validate the packet authentication. HIT 191 SHOULD be unique in the whole IP universe. If there is more than 192 one public key for a HIT, the HIT acts as a hint for the correct 193 public key to use. 195 There are two formats for HIT. These two formats are designed to 196 avoid the most commonly occurring IPv6 addresses in RFC 2373 197 [RFC2372]. Bits 0 and 1 are used to differentiate the formats. If 198 Bit 0 is zero and Bit 1 is one, then the rest of HIT is a 126 bits 199 of a Hash of the key. For example, if the Identity is DSA, these 200 bits MUST be the least significant 126 bits of the SHA-1 [FIPS-180- 201 1] hash of the DSA public key Host Identity. 203 If Bit 0 is one and Bit 1 is zero, then the next 62 bits is the Host 204 Assigning Authority (HAA) field, and only the last 64 bits come from 205 a SHA-1 hash of the Host Identity. This format for HIT is 206 recommended for 'well known' systems. It is possible to support a 207 resolution mechanism for these names in directories like DNS. 208 Another use of HAA is in policy controls. 210 The birthday paradox sets a bound for the expectation of collisions. 211 It is based on the square root of the number of values. A 64-bit 212 hash, then, would put the chances of a collision at 50-50 with 2^32 213 hosts (4 billion). A 1% chance of collision would occur in a 214 population of 640M and a .001% collision chance in a 20M population. 216 Moskowitz 4 217 Host Identity Payload November 2001 219 A 128 bit hash will have the same .001% collision chance in a 220 9x10^16 population. 222 Allocation Prefix Fraction of IPv6 223 (binary) Address Space 224 ------------------------ -------- ------------- 226 IPv6 Address space 00 1/4 227 126 bit HIT 01 228 HAA assigned 64 bit HIT 10 229 IPv6 Address space 11 1/4 231 4.2.1. Storing HIT in DNS 233 The HIT SHOULD be stored in DNS. The exception to this is anonymous 234 identities. The HIT is stored in a new KEY RR. The HIT KEY RR will 235 have all flags set to ZERO, its protocol set to HIP, and algorithm 236 set to HIT128. The 'public key' field of the HIT KEY RR will be the 237 128 bit HIT. 239 4.3. Host Assigning Authority (HAA) field 241 The 62 bits of HAA supports two levels of delegation. The first is 242 a registered assigning authority (RAA). The second is a registered 243 identity (RI, commonly a company). The RAA is 22 bits with values 244 assign sequentially by ICANN. The RI is 40 bits, also assigned 245 sequentially but by the RAA. This can be used to create a 246 resolution mechanism in the DNS. For example if FOO is RAA number 247 100 and BAR is FOO's 50th registered identity, and if 248 1385D17FC63961F5 is the hash of the key for www.foo.com, then by 249 using DNS Binary Labels [DNSBIN] there could be a reverse lookup 250 record like: 252 \[x1385D17FC63961F5/64].\[x32/40].\[x64/22].HIT.int IN PTR 253 www.foo.com. 255 4.4. Local Scope Identity (LSI) 257 LSIs are 32-bit localized representations of a Host Identity. The 258 purpose of an LSI is to facilitate using Host Identities in existing 259 protocols and APIs. The owner of the Host Identity does not set its 260 own LSI; each host selects its partner's 32 bit representation for a 261 Host Identity. LSI assignment is sequential off of a random 262 starting point. That is, at kernel initiation, a random starting 263 point is selected for LSIs, and they are assigned sequentially 264 thereafter. This avoids collisions if LSIs are assigned 265 sequentially starting from zero, and even collisions on a busy host 266 if assigned randomly. The risk of collisions for random assignment 267 is 1% in a population of 10,000. 269 Moskowitz 5 270 Host Identity Payload November 2001 272 Examples of how LSIs can be used include: as the address in a FTP 273 command and as the address in a socket call. Thus LSIs act as a 274 bridge for Host Identity into old protocols and APIs. 276 4.5. Security Parameter Index (SPI) 278 SPIs are used in ESP to index into the security association 279 negotiated in HIP. The ESP SPIs have added significance when used 280 with HIP; they are a compressed representation of the HIT in every 281 packet. Thus they MAY be used by intermediary systems in providing 282 services like address mapping. A system does not set its own SPI; 283 each host selects its partner's SPI. It MUST be random. The risk 284 of collisions is too great (1% in a population of 10,000). 286 A different SPI MUST be used for each HIP exchange with a particular 287 host; this is to avoid a replay attack. Additionally, when a host 288 rekeys, the SPI MUST change. One method for SPI creation that meets 289 these criteria, would be to concatenate the HIT with a 32 bit random 290 number, hash this (using SHA1), and then use the high order 32 bits 291 as the SPI. 293 4.6. Difference between an LSI and the SPI 295 There is a subtle difference between an LSI and a SPI. 297 The LSI is relatively longed lived. A system selects its peer's LSI 298 and SHOULD reuse a previous LSI for a HIT during a HIP exchange. 299 This COULD be important in a timeout recovery situation. The LSI 300 ONLY appears in the 3rd and 4th HIP packets (each system providing 301 the other with its LSI). The LSI is used anywhere in system 302 processes where IP addresses have traditionally have been used, like 303 in TCBs and FTP port commands. 305 The SPI is short-lived. It changes with each HIP exchange and with 306 a HIP rekey. A system notifies its peer of the SPI to use in ESP 307 packets sent to it. Since the SPI is in all but the first two HIP 308 packets, it can be used in intermediary systems to assist in address 309 remapping. 311 5. The Host Identity Payload 313 The Host Identity Payload or HIP is IP protocol NN. HIP could be 314 carried in every datagram. However, since HIP datagrams are 315 relatively large (at least 20 bytes), and ESP already has all of the 316 functionality to maintain and protect state, the HIP payload is 317 'compressed' into an ESP payload after the HIP exchange. Thus in 318 practice, HIP packets only occur in datagrams to establish or change 319 HIP state. 321 Moskowitz 6 322 Host Identity Payload November 2001 324 5.1. HIP format 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Next Header | Payload Len | Type | VER. | RES. | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 | Host Identity Tag (HIT) | 333 | | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 | HIP Key payload | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | ESP followed by IP payload (opt) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Next Header WILL be zero for those HIP packets that do not carry a 344 transport layer. Thus Next Header SHOULD only be zero or 50 (ESP). 346 Payload length is the length, in bytes, of the optional HIP Key 347 payload. It is zero if there is no payload. Thus the length of the 348 HIP envelope is 20 plus the payload length. 350 The Type indicates which HIP packet this is. 352 The HIP Version is one byte. The current version is 1. 354 The HIT is always 128 bits (16 bytes). 356 5.2. HIP Key Payload 358 The HIP Key Payload is used to carry the public key associated with 359 the HIT and related security information. The format of the HIP Key 360 Payload is a simplification of a DNS message [DNS]. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | RCOUNT | FQDNLGTH | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 / FQDN / 369 / / 370 | 0 � 7 bytes padding | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | RDLENGTH | TYPE | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Moskowitz 7 376 Host Identity Payload November 2001 378 | | 379 / RDATA / 380 / / 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 . . 384 . . 385 . . 387 RCOUNT is the number of HIP Resource Records. If the sender does 388 not have (or does not wish to divulge) an FQDN, a value of '.' will 389 be used. The sender arbitrarily selects the content of the padding 390 field. 392 The HIP Resource Records will either be a KEY (e.g. DSA and D-H), 393 SIG [DNSSEC], A, AAAA, or OPT [EDNS] record. The RDATA of the OPT 394 record in the payload can contain any of the following: 396 OPT Attribute Length Data 398 Remotes_HIT 128 Remote's HIT 399 HIP_CNTLS variable contains bit-wise controls 400 HIP_COOKIE 192 3 64 bit fields: 401 Random # I, 402 K or random # J, 403 Hash target, Ltrunc(SHA1(I|J)) 404 or Utrunc(SHA1(I|J)) 405 HIP_TRANSFORM variable ISAKMP Transform (Appendix A) 406 Without first 32 bits 407 Using IPsec DOI 408 ESP_TRANSFORM variable ISAKMP Transform (Appendix A) 409 Without first 32 bits 410 Using IPsec DOI 411 Birthday 64 System boot counter 412 Remotes_LSI 32 Remote's LSI 413 Remotes_SPI 32 Remote's SPI 414 Sequence Number 32 Current ESP sequence number 415 ID 64 Name of a network Interface 417 5.3. HIP Cookie Exchange 419 The HIP cookie exchange serves to manage the establishment of state 420 between the Initiator and Responder. This cookie exchange is 421 different than other 3-way exchanges in that the Responder starts 422 the exchange. Since the Responder starts the exchange, it can set 423 the difficulty for the Initiator. The Responder supplies a random 424 number I, and requires the Initiator hash it with a random number J. 425 The resulting hash's lowest order K bits MUST match a hash target 426 also supplied by the Responder. To accomplish this, the Initiator 427 will have to generate a number of Js until one produces the hash 428 target; the worst case SHOULD be 2^K hash operations. The Responder 430 Moskowitz 8 431 Host Identity Payload November 2001 433 needs only hash the Initiator's J with its I to prove that the 434 Initiator did its assigned task. 436 Thus the Responder can set the difficulty for Initiator, based on 437 its concern of trust of the Initiator. 439 5.3.1. HIP Cookie Mechanism 441 Responder Generates 2 Random Numbers, I and J 442 Challenge = Ltrunc(SHA1(I|J),K) 443 Send I, K, and Challenge in HIP Cookie in R1 444 Saves I, K, and Challenge for Delta time 446 Initiator Do Until Challenge-response = Challenge 447 Challenge-response = Ltrunc(SHA1(I|Rand),K) 448 EndDo 449 Send I, Rand, and Challenge-response in HIP Cookie 450 in I2 452 Responder Match Response with Challenge based on I 453 Reject if Challenge-response = Challenge 454 Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K) 455 Accept if Challenge-proof = Challenge 457 5.3.2. HIP Controls 459 HIP controls are informative items that will influence the HIP 460 exchange and the use of ESP. HIP Controls are assigned a bit 461 location in the HIP_CNTL field numbered left to right. Currently, 462 there are two controls of value to a HIP exchange: 464 BIT Action 466 0 If value is 1, the HI is anonymous. 467 This control is set in packets R1 and/or I2. 468 The peer receiving an anonymous HI may choose to refuse it by 469 silently dropping the exchange. 470 1 If value is 1, the ESP transform requires a 64 bit sequence 471 number. See Sequence Number section for processing this 472 control. 474 Various controls will be defined over time. These controls will be 475 added to the end of the HIP_CNTL field so that older implementations 476 can ignore them. 478 5.3.3. HIP Birthday 480 The Birthday is a reboot count used to manage state reestablishment 481 when one peer rebooted or timed out its SA. The Birthday is 482 increased every time the system boots. The Birthday also has to be 484 Moskowitz 9 485 Host Identity Payload November 2001 487 increased in accordance with the system's SA timeout parameter. If 488 the system has open SAs, it MUST increase its Birthday. This 489 impacts a system's approach to precomputing R1 packets. 491 Birthday SHOULD be a counter. It cannot be reset by the user and a 492 system is unlikely to need a birthday larger than 2^64. Date-time in 493 GMT can be used if a cross-boot counter is not possible, but it has 494 a potential problem if the system time is set back by the user. 496 6. HIP Packets 498 There are 7 HIP packets. Four are for the HIP exchange, two are for 499 mid-state changes (rekeying and address migration), and one is a 500 broadcast for use when there is no IP addressing (e.g. before DHCP 501 exchange). 503 Although HIP is presented to operate above IP, it MAY be used below 504 IP to support MAC layer protocols like DHCP. However, there is no 505 MAC layer relaying mechanism defined like that defined in DHCP. 507 All implementations MUST parse at least the following formats. All 508 implementations MUST recognize additional RR in the HIP envelope but 509 MAY ignore them. 511 Packet representation uses the following operations: 513 () payload 514 x{} operation x on contents 515 <>i repeat () 1 to n times 516 [] optional payload 518 An ESP payload MAY follow some HIP payloads. This transmission 519 optimization SHOULD NOT be used if it results in fragmentation, and 520 there would not be any fragmentation if the ESP payload were sent by 521 itself. 523 6.1. I1 - the HIP Initiator packet 525 Next Header = 0 526 Type = 1 527 HIT = Initiator's HIT 528 Payload Contains: 529 Responder's HIT in a KEY HIT RR 531 IP(HIP(HITr)) 533 The Initiator gets the responder's HIT either from a DNS lookup of 534 the responder's FQDN or from a local table. 536 Since this packet is so easy to spoof even if it were signed, no 537 attempt is made to add to its generation or processing cost. 539 Moskowitz 10 540 Host Identity Payload November 2001 542 Implementation MUST be able to handle a storm of I1 packets, 543 discarding those with common content that arrive within a small time 544 delta. 546 6.2. R1 - the HIP Responder packet 548 Next Header = 0 549 Type = 2 550 HIT = Responder's HIT 551 Payload Contains: 552 HIP CONTROLs in an OPT RR 553 Responder's HI in a KEY RR (e.g. KEY DSA RR) 554 Optional SIG of Responder's HI by a signing authority 555 in a SIG RR 556 Responder's Diffie-Hellman public value in a KEY DH RR 557 Birthday 558 HIP TRANSFORM in an OPT RR 559 ESP TRANSFORM in an OPT RR 560 HIP COOKIE in an OPT RR 561 HIP SIG in a SIG RR 563 IP(HIP(H_CTRL,HIr,[AUTH_SIG,] DHr,BRTHDY,H_TRN,E_TRN,COOKIE1,SIG)) 565 The valid HIP control is the anonymous bit. 567 If the responder has multiple HIs, the HIT used MUST match 568 Initiator's request. 570 The Optional Signature of the Responder's HI by a higher level 571 authority known to the Initiator is an alternative method for the 572 Initiator to trust the Responder's HI (over DNSSEC or PKI). 574 The Diffie-Hellman value is ephemeral, but can be reused over a 575 number of connections. In fact, as a defense against I1 storms, an 576 implementation MAY use the same Diffie-Hellman value for a period of 577 time, for example 15 minutes. By using a small number of Is for a 578 given Diffie-Hellman value, the R1 packets can be pre-computed and 579 delivered as quickly as I1 packets arrive. A scavenger process 580 should clean up unused DHs and Is. 582 The Birthday is a reboot count used to manage state reestablishment 583 when one peer rebooted or timed out its SA. 585 The HIP_TRANSFORM contains the encryption algorithms supported by 586 the responder to protect the HI exchange, in order of preference. 588 The ESP_TRANSFORM contains the ESP modes supported by the responder, 589 in order of preference. 591 HIP_COOKIE contains random I, K, and Hash Target. I is an internal 592 pointer to the HI, HIT, and DH sent to the Initiator. It is only 594 Moskowitz 11 595 Host Identity Payload November 2001 597 used as a pointer until this cookie is used in an SA. K is number 598 of bits that the Initiator must match with the Hash Target. 600 The HIP SIG is calculated over the whole HIP envelope. The Initiator 601 MUST validate this SIG. It MAY use either the HI in the packet or 602 the HI from a DNS query. 604 6.2.1. R1 Management 606 All compliant implementations MUST produce R1 packets. 607 An R1 packet MAY be precomputed. 608 An R1 packet MAY be reused for time Delta T. 609 R1 information MUST not be discarded until Delta S after T. Time S 610 is the delay needed for the last I2 to arrive back to the responder. 611 A spoofed I1 can result in an R1 attack on a system. An R1 sender 612 MUST have a mechanism to rate limit R1s to an address. 614 6.3. I2 - the HIP Second Initiator packet 616 Next Header = 0 or 50 (ESP) 617 Type = 3 618 HIT = Initiator's HIT 619 Payload Contains: 620 HIP CONTROLs in an OPT RR 621 Responder's HIT in a KEY HIT RR 622 Birthday 623 HIP COOKIE in an OPT RR 624 Responder's LSI in an OPT RR 625 Responder's SPI in an OPT RR 626 Initiator's Diffie-Hellman public value in a KEY DH RR 627 HIP TRANSFORM in an OPT RR 628 The following Resource Records are encrypted using the HIP 629 Transform and are in a HIP ENCRPYT OPT RR 630 ESP TRANSFORM in an OPT RR 631 Initiator's HI in a KEY RR (e.g. KEY DSA RR) 632 Optional SIG of Initiator's HI by a signing authority 633 in a SIG RR 634 HIP SIG in a SIG RR 635 Optional data in an ESP envelope 637 IP(HIP(H_CTRL,HITr,BRTHDY,COOKIE2,LSIr,SPIr,DHi,H_TRN,enc{E_TRN,HIi 638 [,AUTH_SIG]},SIG)[ESP(data)]) 640 The valid HIP controls are the anonymous and 64 bit sequence number 641 bits. 643 If the initiator has multiple HIs, the HI and HIT used MUST match 644 Responder's reply. 646 The Birthday is a reboot count used to manage state reestablishment 647 when one peer rebooted or timed out its SA. 649 Moskowitz 12 650 Host Identity Payload November 2001 652 HIP_COOKIE contains I from R1 and random J, and Ltrunc(SHA1(I|J), K) 653 (that is the low order K bits of the SHA1 of I concatenated with J). 654 The low order K bits of Ltrunc(SHA1(I|J)) MUST match the low order K 655 bits of the Hash Target. J is an internal pointer to the HI, HIT, 656 and DH sent to the Responder. 658 The Diffie-Hellman value is ephemeral. A scavenger process should 659 clean up unused DHs and Js. 661 The HIP_TRANSFORM contains the encryption used to protect the HI 662 exchange selected by the initiator. All implementations MUST 663 support the 3DES transform. 665 The ESP_TRANSFORM, Initiator's HI, and optional SIG on this HI are 666 encrypted using the HIP_TRANSFORM. The keying material is derived 667 from the Diffie-Hellman exchanged as defined later in this document. 669 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 670 All implementations MUST support 3DES-HMAC-SHA-1-96, RFCs 2404 and 671 2451. 673 The Optional Signature of the Initiator's HI by a higher level 674 authority known to the Responder is an alternative method for the 675 Responder to trust the Initiator's HI (over DNSSEC or PKI). 677 The HIP SIG is calculated over whole HIP envelope. The Responder 678 MUST validate this SIG. It MAY use either the HI in the packet or 679 the HI from a DNS query. 681 The optional ESP payload contains the first user datagram that the 682 Initiator is sending to the Responder. The SPI is set to NN, as the 683 real Initiator SPI is not know yet be the Initiator. When the 684 Responder processes the HIP payload, it generates the Initiator SPI 685 and replaces NN with this SPI. The Sequence Number SHOULD be set to 686 ONE, as this is the first datagram for this SA. If the ESP 687 transform uses the ESP header for the IV, then special 688 considerations for the ESP header might apply. For example, if the 689 transform requires a random value in the header, expecting it to be 690 the SPI, the Sequence Number can be a random number, and be reset to 691 ONE by the Responder. The Responder would pass the Initiator 692 supplied SPI and Sequence Number to the decryption routine. 694 6.4. R2 - the HIP Second Responder packet 696 Next Header = 0 or 50 (ESP) 697 Type = 4 698 HIT = Responder's HIT 699 Payload Contains: 700 HIP CONTROLs in an OPT RR 701 Initiator's LSI in an OPT RR 702 Initiator's SPI in an OPT RR 704 Moskowitz 13 705 Host Identity Payload November 2001 707 HIP SIG in a SIG RR 708 Optional data in an ESP envelope 710 IP(HIP(H_CTRL,LSIi,SPIi,SIG)[ESP(data)]) 712 The valid HIP control is the 64 bit sequence number bit. 714 The HIP SIG is calculated over whole HIP envelope. The Initiator 715 MUST validate this SIG. 717 The optional ESP payload contains the first user datagram that the 718 Responder is sending to the Initiator. The SPI is the value within 719 I2. The Sequence Number MUST be set to ONE, as this is the first 720 datagram for this SA. 722 6.5. NES - the HIP New SPI Packet 724 The HIP New SPI Packet serves three functions. First it provides 725 the peer system with its new SPI. Next it optionally provides a new 726 Diffie-Hellman key to produce new keying material. Additionally, it 727 provides any intermediate system with the mapping of the old SPI to 728 the new. This is important to systems like NATs [HIPIMPL] that use 729 SPIs to maintain address translation state. The new SPI Packet is a 730 HIP packet with SPI and D-H OPT RRs in the HIP payload. The HIP 731 packet contains the current ESP Sequence Number and SPI to provide 732 Dos and replay protection. 734 The HIP content is: 736 Next Header = 0 737 Type = 5 738 HIT = Sender's HIT 739 Payload Contains: 740 Sender's ESP Sequence Number in an OPT RR 741 Sender's old SPI in an OPT RR 742 Sender's new SPI in an OPT RR 743 Optional Sender's Diffie-Hellman public value in a KEY DH RR 744 HIP SIG in a SIG RR 745 Optional data in an ESP envelope 746 In reply packet only 748 IP(HIP(SEQ,SPIo,SPI[,DH],SIG)[ESP(data)]) 750 During the life of an SA established by HIP, one of the hosts may 751 need to reset the Sequence Number to one (to prevent wrapping) and 752 rekey. The reason for rekeying might be an approaching sequence 753 number wrap in ESP, or a local policy on use of a key. A new SPI or 754 rekeying ends the current SA and starts a new one on both peers. 756 The ESP Sequence Number and current SPI are included to provide 757 replay protection for the receiving peer. This packet MUST NOT be 758 processed until all ESP packets with a lower Sequence Number have 760 Moskowitz 14 761 Host Identity Payload November 2001 763 been received and processed, or a reasonable time has elapsed (to 764 account for lost packets). If the Sequence Number is a replay 765 window greater than the current number it MUST be ignored. This 766 packet has a potential Dos attack of a packet within the replay 767 window and proper SPI, but a malformed signature. Implementations 768 MUST recognize when they are under attack and manage the attack. If 769 it is still receiving ESP packets with increasing Sequence Numbers, 770 the HIP new SPI packets are obviously attacks and can be ignored. 772 Intermediate systems that use the SPI will have to inspect ALL HIP 773 packets for a HIP New SPI packet. This is a potential DOS attack 774 against the Intermediate system, as the signature processing may be 775 relatively expensive. A further step against attack for the 776 Intermediate systems is to implement ESP's replay protection of 777 windowing the sequence number. This requires the intermediate 778 system to track ALL ESP packets to follow the Sequence Number. 780 The peer that initiates a New SPI exchange MUST include a Diffie- 781 Hellmen key. Its peer MUST respond with a New SPI packet, an MAY 782 include a Diffie-Hellman key if the receiving system's policy is to 783 increase the new KEYMAT by changing its key pair. 785 When a host receives a New SPI Packet with a Diffie-Hellman, its 786 next ESP packet MUST use the KEYMAT generated by the new Kij. The 787 sending host MUST expect at least a replay window worth of ESP 788 packets using the old Kij. Out of order delivery could result in 789 needing the old Kij after packets start arriving using the new SA's 790 Kij. Once past the rekeying start, the sending host can drop the 791 old SA and its Kij. 793 The first packet sent by the receiving system MUST be a HIP New SPI 794 packet. It MAY also include a datagram, using the new SAs. This 795 packet supplies the new SPI for the rekeying system, which cannot 796 send any packets until it receives this packet. If it does not 797 receive a HIP New SPI packet within a reasonable round trip delta, 798 it MUST assume it or the HIP Rekey packet was lost and MAY resend 799 the HIP New SPI packet or renegotiate HIP as if in a reboot 800 condition. The choice is a local policy decision. 802 6.6. REA - the HIP Readdress Packet 804 During the life of a Security Association established by HIP, one of 805 the hosts may change its IP address. The reason for readdressing 806 might be a PPP reconnect, DHCP new lease, or IPv6 address prefix 807 change. The readdressing event might be from mobility or Internet 808 reconnection. This readdress packet is NOT intended to provide all 809 of the functionality needed for MobileIPv6, or even a mobile server. 810 This functionality is provided in a separate specification. 811 Although HIP enables ESP to be independent of the internetworking 812 layer, there still needs to be a mapping of the LSI and HIT to an IP 813 address. 815 Moskowitz 15 816 Host Identity Payload November 2001 818 The Readdress Packet permits a host to notify its partners of an 819 address change. The Readdress Packet is a HIP packet with at least 820 one pair of A or AAAA RRs in the HIP payload. The address RR is 821 included in the HIP payload not for the partner's benefit (which 822 COULD deduce this from the outer IP header), but for benefit of any 823 intermediary systems that are maintaining state between the HIT and 824 the address. If the readdressed host 'knew' that there were no 825 intermediary systems between it and its partners, it COULD remove 826 the address RR here for architectural purity. However, this option 827 would only further complicate the protocol. 829 The HIP packet contains the current ESP Sequence Number and SPI to 830 provide Dos and replay protection. 832 The HIP content is: 834 Next Header = 0 or 50 (ESP) 835 Type = 6 836 HIT = Sender's HIT 837 Payload Contains: 838 Sequence number in an OPT RR 839 Current SPI 840 Interface ID in an OPT RR 841 New address in an A or AAAA RR 842 HIP SIG in a SIG RR 843 Optional data in an ESP envelope 845 IP(HIP(SEQ,SPI,<[ID,]j>i,SIG)[ESP(data)]) 847 The address OPT RRs are always in pairs, the old address and the new 848 address. Multiple addresses can be sent in a single HIP payload. 850 The Interface ID, if included, groups a set of addresses to an 851 interface. The purpose of the Interface ID is to allow a 852 knowledgeable peer to interact with the sender. For example, the 853 sender could be informing its peer that that an interface has both 854 an IPv4 address and one or more IPv6 addresses. The HIP host is 855 free to introduce IDs at will. That is, if a received REA has a new 856 interface ID, it means that all the old addresses are also supposed 857 to still work, while the new addresses in the REA are supposed to be 858 associated with a new interface. On the other hand, if a received 859 REA has an interface ID that the receiver already knows about, it 860 would replace (all) the address(es) currently associated with the 861 interface with the new one(s). 863 The ESP Sequence Number and current SPI are included to provide 864 replay protection for the receiving peer. This packet MUST NOT be 865 processed until all ESP packets with a lower Sequence Number have 866 been received and processed, or a reasonable time has elapsed (to 867 account for lost packets). If the Sequence Number is a replay 868 window greater than the current number it MUST be ignored. This 869 packet has a potential Dos attack of a packet within the replay 870 window and proper SPI, but a malformed signature. Implementations 872 Moskowitz 16 873 Host Identity Payload November 2001 875 MUST recognize when they are under attack and manage the attack. If 876 it is still receiving ESP packets with increasing Sequence Numbers, 877 the HIP readdress packets are obviously attacks and can be ignored. 879 Intermediate systems that use the SPI will have to inspect ALL HIP 880 packets for a HIP readdress packet. This is a potential DOS attack 881 against the Intermediate system, as the signature processing may be 882 relatively expensive. A further step against attack for the 883 Intermediate systems is to implement ESP's replay protection of 884 windowing the sequence number. This requires the intermediate 885 system to track ALL ESP packets to follow the Sequence Number. 887 The optional ESP protected datagram allows for efficiency in 888 transmissions. 890 6.7. BOS - the HIP Bootstrap Packet 892 The HIP content is: 894 Next Header = 0 895 Type = 10 896 HIT = Announcer's HIT 897 Payload Contains: 898 Announcer's HIT in a KEY HIT RR 899 Announcer's HI in a KEY RR (e.g. KEY DSA RR) 900 Optional SIG of Announcer's HI by a signing authority 901 in a SIG RR 902 HIP SIG in a SIG RR 904 IP(HIP(HIT,HI,[AUTH_SIG,] SIG))) 906 In some situations, an initiator may not be able to learn of a 907 responder's information from DNS or another repository. Some 908 examples of this are DHCP and NetBios servers. Thus a packet is 909 needed to provide information that would otherwise be gleaned from a 910 repository. This HIP packet is either self-signed in applications 911 like SoHo, or from a trust anchor in large private or public 912 deployments. This packet SHOULD be broadcasted frequently. 914 The Optional Signature of the Announcer's HI by a higher level 915 authority known to the Initiator is an alternative method for the 916 Initiator to trust the Announcer's HI (over DNSSEC or PKI). 918 6.8. HIP Fragmentation Support 920 A HIP implementation MUST support IP fragmentation/reassembly. HIP 921 packets can get large, and may encounter low MTUs along their routed 922 path. Since HIP does not provide a mechanism to use multiple IP 923 datagrams for a single HIP packet, support of path MTU discovery 924 does not bring any value to HIP. HIP aware NAT systems MUST perform 925 any IP reassembly/fragmentation. 927 Moskowitz 17 928 Host Identity Payload November 2001 930 7. ESP with HIP 932 HIP sets up a Security Association (SA) to enable ESP in an end-to- 933 end manner that can span addressing realms (i.e. across NATs). This 934 is accomplished through the various informations that are exchanged 935 within HIP. It is anticipated that since HIP is designed for host 936 usage, that is not for gateways, that only ESP transport mode will 937 be supported with HIP. The SA is not bound to an IP address; all 938 internal control of the SA is by the HIT and LSI. Thus a host can 939 easily change its address using Mobile IP, DHCP, PPP, or IPv6 940 readdressing and still maintain the SA. And since the transports 941 are bound to the SA (LSI), any active transport is also maintained. 942 So real world conditions like loss of a PPP connection and its 943 reestablishment or a mobile cell change will not require a HIP 944 negotiation or disruption of transport services. 946 Since HIP does not negotiate any lifetimes, all lifetimes are local 947 policy. The only lifetimes a HIP implementation MUST support are 948 sequence number rollover (for replay protection), and SA timeout. 949 An SA times out if no packets are received using that SA. The 950 default timeout value is 15 minutes. Implementations MAY support 951 lifetimes for the various ESP transforms. Note that HIP does not 952 offer any service comparable with IKE's Quick Mode. A Diffie- 953 Hellman calculation is needed for each rekeying. 955 7.1. Security Association Management 957 An SA is indexed by the 2 SPIs and 2 HITs (both HITs since a system 958 can have more than one HIT). 959 An inactivity timer is recommended for all SAs. 960 If the state dictates the deletion of an SA, a timer is set to allow 961 for any late arriving packets. 962 The SA MUST include the I that created it for replay detection. 964 7.2. Security Parameters Index (SPI) 966 The SPIs in ESP provide a simple compression of the HIP data from 967 all packets after the HIP exchange. This does require a per HIT- 968 pair Security Association (and SPI), and a decrease of policy 969 granularity over other KMPs like IKE. 971 When a host rekeys, it gets a new SPI from its partner. 973 7.3. Supported Transforms 975 All HIP implementations MUST support 3DES [3DES] and HMAC-SHA-1-96 976 [HMACSHA1]. If the Initiator does not support any of the transforms 977 offered by the Responder in the R1 HIP packet, it MUST use 3DES and 978 HMAC-SHA-1-96 and state so in the I2 HIP packet. 980 Moskowitz 18 981 Host Identity Payload November 2001 983 7.4. Sequence Number 985 The Sequence Number field is MANDATORY in ESP. Anti-replay 986 protection MUST be used in an ESP SA established with HIP. 988 This means that each host MUST rekey before its sequence number 989 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 990 one Diffie-Hellman key can be changed, that of the rekeying host. 991 However, if one host rekeys, the other host SHOULD rekey as well. 993 In some instances, a 32 bit sequence number is inadequate. In 994 either the I2 or R2 packets, a peer MAY require that a 64 bit 995 sequence number be used. In this case the higher 32 bits are NOT 996 included in the ESP header, but are simply kept local to both peers. 997 64 bit sequence numbers must only be used for ciphers that will not 998 be open to cryptoanalysis as a result. AES is one such cipher. 1000 7.5. ESP usage with non-cryptographic HI 1002 Even if the Host Identity is not cryptographically based, ESP MUST 1003 still be used after the HIP exchange between the two hosts. The HIP 1004 TRANSFORM in this case will be left out of the HIP exchange, and the 1005 ESP envelope will not have any authentication of encryption. The 1006 purpose of using ESP in this situation is to have the SPI (LSI) for 1007 associating the packets with the HITs, and the sequence # for replay 1008 protection. 1010 8. The Host Layer Protocol (HLP) packet flow 1012 A Host Layer Protocol (HLP) exchange SHOULD be initiated whenever 1013 the DNS lookup returns HIP KEY resource records. Since some hosts 1014 may choose not to have information in DNS, hosts SHOULD support 1015 opportunistic HIP [HIPIMPL]. 1017 Only Initiator and Responder in common addressing realm (i.e. both 1018 public or both private) is shown here. Other packet flow scenarios 1019 are covered in the HIP implementation documents. 1021 8.1. The Host Layer Protocol (HLP) 1023 Initiator gets IP address, HI, and HIT of Responder somehow. 1024 Hard coded (bad) 1025 DNS lookup 1026 DNSSEC important 1028 I --> DNS (lookup R) 1029 I <-- DNS (R's address, HI, and HIT) 1030 I1 I --> R (Hi. Here is my I1, let's talk HIP) 1031 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 1033 Moskowitz 19 1034 Host Identity Payload November 2001 1036 I2 I --> R (Compute, compute, here is my counter I2) 1037 R2 I <-- R (OK. Let's finish HIP cookie with my R2) 1038 I --> R (ESP protected data) 1039 I <-- R (ESP protected data) 1041 8.2. HLP Scenarios 1043 No prior state between the two systems. 1045 The system with data to send is the Initiator. 1046 The process follows standard 4 packet exchange, establishing 1047 the SAs. 1049 The system with data to send has no state with receiver, but 1050 receiver has a residual SA. 1052 Intiator acts as in no prior state, sending I1 and getting R1. 1053 When Receiver gets I2, the old SA is 'discovered' and deleted; 1054 the new SAs are established. 1056 System with data to send has an SA, but receiver does not. 1058 Receiver 'detects' when it receives an unknown SPI. 1059 Receiver sends an R1. 1060 Sender gets the R1 with a later birthdate, discards old SA and 1061 continues exchange to establish new SAs for sending data. 1063 A peer determines that it needs to reset Sequence number or rekey. 1064 It sends NES. 1065 Receiver sends NES response, establishes new SAs for peers. 1066 D-H optional for peer that received the first NES. 1068 8.3. HIP KEYMAT 1070 HIP keying material is derived from the Diffie-Hellman Kij produced 1071 during the HLP exchange. The initiator has Kij during the creation 1072 or the I2 packet, and the responder has Kij once it receives the I2 1073 packet. This is why I2 can already contain encrypted information. 1074 There are four keys that are derived from Kij; these are the 1075 initiator and responder HIP keys and the initiator and responder ESP 1076 keys. These four keys MUST be drawn sequentially (HIP initiator, 1077 HIP responder, ESP initiator, EXP responder, and where the ESP 1078 transform requires an encrypting and an authenticating key, they are 1079 taken sequentially) from the Kij KEYMAT. For situations where the 1080 amount of keying material desired is greater than that supplied by 1081 Kij, KEYMAT is expanded by feeding Kij into the following operation: 1083 KEYMAT = K1 | K2 | K3 | ... 1084 where 1086 K1 = HMAC-SHA1(Kij | sort(Resp-SPI | Init-SPI) | 1) 1088 Moskowitz 20 1089 Host Identity Payload November 2001 1091 K2 = HMAC-SHA1(Kij | K1 | 2) 1092 K3 = HMAC-SHA1(Kij | K2 | 3) 1093 etc. 1095 In the situation where Kij is the result of a HIP rekey exchange, 1096 there is only the need from one set of ESP keys. These are then the 1097 only keys taken from Kij. 1099 8.4. Refusing a HLP exchange 1101 A HIP aware host may choose not to accept a HLP exchange. If the 1102 host's policy is to only be an initiator, it should begin its own 1103 HLP exchange. There is a risk of a race condition if each host's 1104 policy is to only be an initiator, at which point the HLP exchange 1105 will fail. 1107 If the host's policy does not permit it to enter into a HLP exchange 1108 with the initiator, it should send an ICMP Host Unreachable, 1109 Administratively Prohibited message. A more complex HIP packet is 1110 not used here as it actually opens up more potential DOS attacks 1111 than a simple ICMP message. 1113 8.5. Reboot and SA timeout restart of HIP 1115 Simulating a loss of state is a potential Dos attack. The following 1116 process has been crafted to manage state recovery without presenting 1117 a Dos opportunity. 1119 If a host reboots or times out, it has lost its HLP state. If the 1120 system that lost state has a datagram to deliver to its peer, it 1121 simply restarts the HLP exchange. The peer sends an R1 HIP packet, 1122 but does not reset its state until it receives the I2 HIP packet. 1123 The I2 packet MUST have a Birthday greater than the current SA's 1124 Birthday. This is to handle DOS attacks that simulate a reboot of a 1125 peer. Note that either the original Initiator or the Responder 1126 could end up restarting the exchange, becoming the Intitator. An 1127 example of the initial Responder needing to send a datagram but not 1128 having state occurs when the SAs timed out and a server on the 1129 Responder sends a keep-alive to the Initiator. 1131 If a system receives an ESP packet for an unknown SPI, the 1132 assumption is it lost state and its peer did not. In this case, the 1133 system treats the ESP packet like an I1 packet and sends an R1 1134 packet. The system receiving the R1 packet checks the Birthday, if 1135 the Birthday is greater than the current SA's Birthday, it processes 1136 the R1 packet and resends the ESP packet along with the I2 packet. 1137 This will reestablish state between the two peers. [Potential Dos 1138 attack if hundreds of peers 'loose' their state and all send R1 1139 packets at once to a server.] 1141 Moskowitz 21 1142 Host Identity Payload November 2001 1144 8.5. HLP State Machine 1146 HLP has very little state. HLP has three processes: SA 1147 establishment, new SPI/rekey, and restart of HLP. In HLP 1148 establishment, there is an Initiator and a Responder. Once the SAs 1149 are established, this distinction is lost. In new SPI/rekey the 1150 Initiator could be either peer. In HLP reestablishment the 1151 controlling parameters are which peer still has state and which has 1152 a datagram to send to its peer. The following state machine 1153 attempts to capture these processes. 1155 The state machine is presented in a single system view, representing 1156 either an Initiator or a Responder. There is not a complete overlap 1157 of processing logic here and in the packet definitions. Both are 1158 needed to completely implement HIP and HLP. 1160 8.5.1. HLP States 1162 E0 State machine start 1163 E1 Initiating HIP 1164 E2 Waiting to finish HIP 1165 E3 HIP SA established 1167 8.5.2. HLP State Processes 1169 +---------+ 1170 | E0 | Start state 1171 +---------+ 1173 Datagram to send, send I1 and go to E1 1174 Receive I1, send R1 and stay at E0 1175 Receive I2, process 1176 if successful, send R2 and go to E3 1177 if fail, stay at E0 1178 Receive ESP for unknown SA, send R1 and stay at E0 1179 Receive ANYOTHER, drop and stay at E0 1181 +---------+ 1182 | E1 | Initiating HLP 1183 +---------+ 1185 Receive R1, process 1186 if successful, send I2 and go to E2 1187 if fail, go to E-FAILED 1188 Receive ANYOTHER, drop and stay at E1 1189 Timeout, up timeout counter 1190 If counter is less than N, send I1 and stay at E1 1191 If counter is greater than N, Go to E-FAILED 1193 +---------+ 1194 | E2 | Waiting to finish HLP 1196 Moskowitz 22 1197 Host Identity Payload November 2001 1199 +---------+ 1201 Receive R2, process 1202 if successful, go to E3 1203 if fail, go to E-FAILED 1204 Receive ANYOTHER, drop and stay at E2 1206 +---------+ 1207 | E3 | HIP SA established 1208 +---------+ 1210 Receive NAS, process 1211 if successful, send NAS and stay at E3 1212 if failed, stay at E3 1213 Receive REA, process and stay at E3 1214 Receive I1, send R1 and stay at E3 1215 Receive I2, process with Birthday check 1216 if successful, send R2, drop old SA and cycle at E3 1217 if fail, stay at E3 1218 Receive R1, process with Birthday check 1219 if successful, send I2 with last datagram, drop old SA 1220 and go to E2 1221 if fail, stay at E3 1222 Receive ESP for SA, process and stay at E3 1223 Receive R2, drop and stay at E3 1225 8.5.3. Simplified HLP State Diagram 1227 Receive packets cause a move to new state 1229 +---------+ 1230 | E0 |----+ 1231 +---------+ | 1232 | ^ | | 1233 | | | Dgm to | 1234 +-+ | send | 1235 I1 | | (note ESP- means ESP with unknown SPI) 1236 ESP- | | 1237 v | 1238 +---------+ | 1239 | E1 | | 1240 +---------+ | 1241 | | 1242 | R1 | 1243 | | I2 1244 v | 1245 +---------+ | 1246 | E2 |<---|-----+ 1247 +---------+ | | 1248 | | | 1249 | R2 | | 1250 | | |R1 1252 Moskowitz 23 1253 Host Identity Payload November 2001 1255 v | | 1256 +---------+<---+ | 1257 | E3 |----------+ 1258 +---------+ 1259 | ^ 1260 | | 1261 +--+ 1262 ESP, 1263 NAS, 1264 REA, 1265 I1, 1266 I2 1268 9. HLP Policies 1270 There are a number of variables that will influence the HLP 1271 exchanges that each host must support. All HIP implementations MUST 1272 support at least 2 HIs, one to publish in DNS and one for anonymous 1273 usage. Although anonymous HIs will be rarely used as responder HIs, 1274 they will be common for initiators. Support for multiple HIs is 1275 recommended. 1277 Many initiators would want to use a different HI for different 1278 responders. The implementations SHOULD provide for an ACL of 1279 initiator HIT to responder HIT. This ACL SHOULD also include 1280 preferred transform and local lifetimes. For HITs with HAAs, 1281 wildcarding SHOULD be supported. Thus if a Community of Interest, 1282 like Banking gets an RAA, a single ACL could be used. A global 1283 wildcard would represent the general policy to be used. Policy 1284 selection would be from most specific to most general. 1286 The value of K used in the HIP R1 packet can also vary by policy. K 1287 should never be greater than 8, but for trusted partners it could be 1288 as low as 1. 1290 Responders would need a similar ACL, representing which hosts they 1291 accept HIP exchanges, and the preferred transform and local 1292 lifetimes. Wildcarding SHOULD be support supported for this ACL 1293 also. 1295 10. Security Considerations 1297 HIP and HLP are designed to provide secure authentication of hosts 1298 and provide a fast key exchange for IPsec ESP. HIP also attempts to 1299 limit the exposure of the host to various denial-of-service and man- 1300 in-the-middle attacks. In so doing, HLP itself is subject to its 1301 own DOS and MITM attacks that potentially could be more damaging to 1302 a host's ability to conduct business as usual. 1304 The Security Association for ESP is indexed by the LSI-SPI, not the 1305 SPI and IP address. HIP enabled ESP is IP address independent. 1307 Moskowitz 24 1308 Host Identity Payload November 2001 1310 This might seem to make it easier for an attacker, but ESP with 1311 replay protection is already as well protected as possible, and the 1312 removal of the IP address as a check should not increase the 1313 exposure of ESP to DOS attacks. 1315 Denial-of-service attacks take advantage of the cost of start of 1316 state for a protocol on the responder compared to the 'cheapness' on 1317 the initiator. HLP makes no attempt to increase the cost of the 1318 start of state on the initiator, but makes an effort to reduce the 1319 cost to the responder. This is done by having the responder start 1320 the 3-way cookie exchange instead of the initiator, making the HLP 1321 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 1322 packet that the responder MAY use many times. The duration of use 1323 is a paranoia versus throughput concern. Using the same Diffie- 1324 Hellman values, I and Hash target has some risk. This risk needs to 1325 be balanced against a potential storm of HIP I1 packets. 1327 This shifting of the start of state cost to the initiator in 1328 creating the I2 HIP packet, presents another DOS attack. The 1329 attacker spoofs the I1 HIP packet and the responder sends out the R1 1330 HIP packet. This could conceivably tie up the 'initiator' with 1331 evaluating the R1 HIP packet, and creating the I2 HIP packet. The 1332 defense against this attack is to simply ignore any R1 packet where 1333 a corresponding I1 was not sent. 1335 A second form of DOS attack arrives in the I2 HIP packet. Once and 1336 attacking initiator has solved the cookie challenge, it can send 1337 packets with spoofed IP source addresses with either invalid 1338 encrypted HIP payload component or a bad HIP SIG. This would take 1339 resources in the responder's part to reach the point to discover 1340 that the I2 packet cannot be completely processed. The defense 1341 against this attack is after N bad I2 packets, the responder would 1342 discard any I2s that contain the given I. Sort of a shutdown on the 1343 attack. The attacker would have to request another R1 and use that 1344 to launch a new attack. The responder could up the value of K while 1345 under attack. On the downside, valid I2s might get dropped too. 1347 A third form of DOS attack is emulating the restart of state after a 1348 reboot of one of the partners. To protect against such an attack, a 1349 system Birthday is included in the R1 and I2 packets to prove loss 1350 of state to a peer. The inclusion of the Birthday creates a very 1351 deterministic process for state restart. Any other action is a Dos 1352 attack. 1354 A fourth form of DOS attack is emulating the end of state. HIP has 1355 no end of state packet. It relies on a local policy timer to end 1356 state. 1358 Man-in-the-middle attacks are difficult to defend against, without 1359 third-party authentication. A skillful MITM could easily handle all 1360 parts of HIP; but HIP indirectly provides the following protection 1361 from a MITM attack. If the responder's HI is retrieved from a 1363 Moskowitz 25 1364 Host Identity Payload November 2001 1366 signed DNS zone by the initiator, the initiator can use this to 1367 validate the R1 HIP packet. 1369 Likewise, if the initiator's HI is in a secure DNS zone, the 1370 responder can retrieve it after it gets the I2 HIP packet and 1371 validate that. However, since an initiator may choose to use an 1372 anonymous HI, it knowingly risks a MITM attack. The responder may 1373 choose not to accept a HLP exchange with an anonymous initiator. 1375 New SPIs and rekeying provide another opportunity for an attacker. 1376 Replay protection is included to prevent a system from accepting an 1377 old new SPI packet. There is still the opening for an attacker to 1378 produce a packet with exactly the right Sequence Number and old SPI 1379 with a malformed signature, consuming considerable computing 1380 resources. All implementations must design to mitigate this attack. 1381 If ESP protected datagrams are still being received; there is an 1382 obvious attack. If the peer is quite, it is easier for an attacker 1383 to launch this sort of attack, but again, the system should be able 1384 to recognize a regular influx of malformed signatures and take some 1385 action. 1387 There is a similar attack centered on the readdress packet. Similar 1388 defense mechanisms are appropriate here. 1390 Since not all hosts will ever support HIP, ICMP 'Destination 1391 Protocol Unreachable' are to be expected and present a DOS attack. 1392 Against an initiator, the attack would look like the responder does 1393 not support HIP, but shortly after receiving the ICMP message, the 1394 initiator would receive a valid R1 HIP packet. Thus to protect 1395 against this attack, an initiator should not react to an ICMP 1396 message until a reasonable delta time to get the real responder's R1 1397 HIP packet. A similar attack against the responder is more 1398 involved. First an ICMP message is expected if the I1 was a DOS 1399 attack and the real owner of the spoofed IP address does not support 1400 HIP. The responder SHOULD NOT act on this ICMP message to remove 1401 the minimal state from the R1 HIP packet, but wait for either a 1402 valid I2 HIP packet or the natural timeout of the R1 HIP packet. 1403 This is to allow for a sophisticated attacker that is trying to 1404 break up the HIP exchange. Likewise, the initiator should ignore 1405 any ICMP message while waiting for an R2 HIP packet, deleting state 1406 only after a natural timeout. 1408 Another MITM attack is simulating a responder's rejection of a HLP 1409 initiation. This is a simple ICMP Host Unreachable, 1410 Administratively Prohibited message. A HIP packet was not used 1411 because it would either have to have unique content, and thus 1412 difficult to generate, resulting in yet another DOS attack, or just 1413 as spoofable as the ICMP message. The defense against this MITM 1414 attack is for the responder to wait a reasonable time period to get 1415 a valid R1 HIP packet. If one does not come, then the Initiator has 1416 to assume that the ICMP message is valid. Since this is the only 1417 point in the HIP exchange where this ICMP message is appropriate, it 1418 can be ignored at any other point in the exchange. 1420 Moskowitz 26 1421 Host Identity Payload November 2001 1423 11. IANA Considerations 1425 IANA has assigned Protocol number XX to HIP. 1427 A new KEY RR protocol of XX is assigned to HIP and an algorithm of 1428 XX is assigned to HIT128. 1430 IANA will has also assigned new DNS OPT resource record OPTION-CODES 1431 of Remotes_HIT [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and 1432 Remotes_LSI [x]. 1434 IANA will assign a SPI of NN for use in the ESP header of the 1435 optional I2 HIP packet. 1437 12. ICANN Considerations 1439 ICANN will need to set up the HIT.int zone and accredit the 1440 registered assigning authorities (RAA) for HAA field. With 21 bits, 1441 ICANN can allocate just over 2M registries. 1443 APPENDIX A. Security Transform Formats 1445 The security transforms, HIP and ESP transforms, use the format from 1446 ISAKMP [ISAKMP]. 1448 0 1 2 3 1449 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 1450 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 / | NP = Transform| RESERVED | Payload Length | 1452 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Tr1| Transform # 1 | Transform ID | RESERVED2 | 1454 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 \ | SA Attributes | 1456 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 / | NP = 0 | RESERVED | Payload Length | 1458 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Tr2| Transform # 2 | Transform ID | RESERVED2 | 1460 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 \ | SA Attributes | 1462 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 Transform Classes Values 1466 HIP_ENC 1 1467 ESP_ENC 2 1468 ESP_AUTH 3 1470 HIP Encryption Algorithm Values [IPSEC-REGISTRY] 1472 Moskowitz 27 1473 Host Identity Payload November 2001 1475 DES-CBC 1 1476 IDEA-CBC 2 1477 Blowfish-CBC 3 1478 RC5-R16-B64-CBC 4 1479 3DES-CBC 5 1480 CAST-CBC 6 1481 AES-CBC 7 1483 ESP Encryption Algorithm Value [ISAKMP-REGISTRY] 1485 RESERVED 0 1486 ESP_DES_IV64 1 1487 ESP_DES 2 1488 ESP_3DES 3 1489 ESP_RC5 4 1490 ESP_IDEA 5 1491 ESP_CAST 6 1492 ESP_BLOWFISH 7 1493 ESP_3IDEA 8 1494 ESP_DES_IV32 9 1495 ESP_RC4 10 1496 ESP_NULL 11 1497 ESP AES 12 1499 ESP Authenticat Algorithm Value 1501 RESERVED 0-1 1502 MD5 2 1503 SHA 3 1504 DES 4 1506 APPENDIX B. Proposed change to the HIP Formats 1508 There is a proposed simplification of the HIP payload. It still 1509 uses a variable format. 1511 The HIP header remains unchanged: 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Next Header | Payload Len | Type | VER. | RES. | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | | 1519 | Host Identity Tag (HIT) | 1520 | | 1521 | | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | RCOUNT | FQDNLGTH | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | | 1527 Moskowitz 28 1528 Host Identity Payload November 2001 1530 / FQDN / 1531 / / 1532 | 0 � 3 bytes padding | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 A change, though is if there is no FQDN, FQDNLGTH = 0 instead of '.' 1536 This saves 4 bytes. Padding of FQDN is also changed to 32 bit 1537 boundry instead of 64 bit. 1539 Each HIP Resource Record will be formated as: 1541 0 1 2 3 1542 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 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | Code | Identifier | RLength | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | | 1547 / RDATA / 1548 / / 1549 | 0 � 3 bytes padding | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Codes are taken from DNS Types: 1554 Name Length 1556 1 A 32 1557 24 SIG variable 1558 25 KEY variable 1559 28 AAAA 128 1560 41 OPT variable 1562 Only Opt uses Identifier: 1564 Name Length 1566 1 HIT 128 1567 2 HIP_CNTLS variable 1568 3 HIP_COOKIE 192 1569 4 HIP_TRANSFORM variable 1570 5 ESP_TRANSFORM variable 1571 6 ENCRYPTED variable 1572 7 BIRTHDAY 64 1573 8 LSI 32 1574 9 SPI 32 1575 10 ID 64 1577 Only I2 uses ENCRYPTED. Encrypted requires a 2-phase parsing. 1578 First it is parsed, then decrypted, and then its contents are 1579 parsed. 1581 There is only one optimization left to consider. That is with 1582 HIP_CNTLS. It COULD be put up in the header: 1584 Moskowitz 29 1585 Host Identity Payload November 2001 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Next Header | Payload Len | Type | VER. | RES. | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | | 1593 | Host Identity Tag (HIT) | 1594 | | 1595 | | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | HIP CONTROLS | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | RCOUNT | FQDNLGTH | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | | 1602 / FQDN / 1603 / / 1604 | 0 � 3 bytes padding | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 This saves one byte in R1, I2, and R2 and costs a byte in I1, NES, 1608 and REA, and any future HIP packet. I am disinclined to do this... 1610 13. References 1612 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 1613 Requirement Levels", RFC 2119, March 1997. 1615 [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", 1616 draft-ietf-moskowitz-hip-arch-03.txt, January 2001. 1618 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 1619 draft-ietf-moskowitz-hip-impl-02.txt, January 2001. 1621 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 1622 Payload", RFC 2406, November 1998. 1624 [RFC2373], R. Hinden, S. Deering., "IP Version 6 Addressing 1625 Architecture", RFC 2373, July 1998. 1627 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1628 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 1629 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 1631 [DNS], Mockapetris, P., "Domain Names - Implementation And 1632 Specification", RFC 1035, November 1987. 1634 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 1635 RFC 2535, March 1999. 1637 Moskowitz 30 1638 Host Identity Payload November 2001 1640 [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 1641 1998. 1643 [3DES], Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 1644 Algorithms", RFC 2451, November 1998. 1646 [HMACSHA1], Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within 1647 ESP and AH", RFC 2404, November 1998. 1649 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1650 "Internet Security Association and Key Management Protocol", RFC 1651 2408, November 1998. 1653 [IPSEC-REGISTRY], 1654 ftp://ftp.isi.edu/in-notes/iana/assignments/ipsec-registry 1656 [ISAKMP-REGISTRY], 1657 ftp://ftp.isi.edu/in-notes/iana/assignments/isakmp-registry 1659 14. Acknowledgments 1661 The drive to create HIP came to being after attending the MALLOC 1662 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave me 1663 the assist to get HIP beyond 5 paragraphs of ideas. It has matured 1664 considerably since the early drafts thanks to extensive input from 1665 IETFers. Most importantly, its design goals are articulated and are 1666 different from other efforts in this direction. Particular mention 1667 goes to the members of the NameSpace Research Group of the IRTF. 1668 Noel Chiappa provided the framework for LSIs and Kieth Moore the 1669 impetuous to provide resolvability. Steve Deering provided 1670 encouragement to keep working, as a solid proposal can act as a 1671 proof of ideas for a research group. 1673 Many others contributed; extensive security tips were provided by 1674 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 1675 Kocher taught me how to make the cookie exchange expensive for the 1676 Initiator to respond, but easy for the Responder to validate. Bill 1677 Sommerfeld supplied the Birthday concept to simplify reboot 1678 management. Rodney Thayer and Hugh Daniels provide extensive 1679 feedback. John Gilmore kept me challenged to provide something of 1680 value. I hope I have. 1682 15. Author's Address 1684 Robert Moskowitz 1685 TruSecure Corporation 1686 1200 Walnut Bottom Rd. 1687 Carlisle, PA 17013 1688 Email: rgm@trusecure.com 1690 Moskowitz 31 1691 Host Identity Payload November 2001 1693 16. Copyright Statement 1695 Copyright (c) The Internet Society (2001). All Rights Reserved. 1696 This document and translations of it may be copied and furnished to 1697 others, and derivative works that comment on or otherwise explain it 1698 or assist in its implementation may be prepared, copied, published 1699 and distributed, in whole or in part, without restriction of any 1700 kind, provided that the above copyright notice and this paragraph 1701 are included on all such copies and derivative works. However, this 1702 document itself may not be modified in any way, such as by removing 1703 the copyright notice or references to the Internet Society or other 1704 Internet organizations, except as needed for the purpose of 1705 developing Internet standards in which case the procedures for 1706 copyrights defined in the Internet Standards process must be 1707 followed, or as required to translate it into languages other than 1708 English. 1710 The limited permissions granted above are perpetual and will not be 1711 revoked by the Internet Society or its successors or assigns. 1713 This document and the information contained herein is provided on an 1714 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1715 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1716 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1717 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1718 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1720 Moskowitz 32