idnits 2.17.1 draft-moskowitz-hip-04.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 3 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 23 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: ---------------------------------------------------------------------------- == Line 872 has weird spacing: '... or Rnm host...' -- 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 (July 2001) is 8321 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 181, but not defined == Missing Reference: 'DNSBIN' is mentioned on line 231, but not defined == Unused Reference: 'RFC2373' is defined on line 1149, 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) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Moskowitz, TruSecure Corp. 2 Internet Draft 3 Document: July 2001 5 Host Identity Payload 6 And Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Table of Contents 31 1. Abstract...........................................................2 32 2. Conventions used in this document..................................2 33 3. Introduction.......................................................2 34 4.1. Host Identity....................................................3 35 4.2. Host Identity Tag (HIT)..........................................4 36 4.2.1. Storing HIT in DNS.............................................5 37 4.3. Host Assigning Authority (HAA) field.............................5 38 4.4. Local Scope Identity (LSI).......................................5 39 4.5. Security Parameter Index (SPI)...................................5 40 4.6. Difference between an LSI and the SPI............................6 41 5. The Host Identity Payload..........................................6 42 5.1. HIP format.......................................................6 43 5.2. HIP Key Payload..................................................7 44 5.3. HIP Cookie Exchange..............................................8 45 6. HIP Packets........................................................8 46 6.1. I1 - the HIP Initiator packet....................................9 47 6.2. R1 - the HIP Responder packet....................................9 48 6.3. I2 - the HIP Second Initiator packet............................10 49 6.4. R2 - the HIP Second Responder packet............................10 51 Moskowitz 1 52 6.5. REK - the HIP Rekey Packet......................................11 53 6.6. NES - the HIP New SPI Packet....................................12 54 6.7. REA - the HIP Readdress Packet..................................13 55 6.8. BOS - the HIP Bootstrap Packet..................................14 56 6.9. HIP Fragmentation Support.......................................14 57 7. ESP with HIP......................................................14 58 7.1. Security Parameters Index (SPI).................................15 59 7.2. Supported Transforms............................................15 60 7.3. Sequence Number.................................................15 61 7.4. ESP usage with non-cryptographic HI.............................15 62 8. HIP Exchange packet flow..........................................15 63 8.1. The HIP Exchange................................................16 64 8.2. HIP KEYMAT......................................................16 65 8.3. Refusing a HIP exchange.........................................16 66 8.4. Reboot restart of HIP...........................................17 67 8.5. Sequence Number State Machine...................................17 68 9. HIP Policies......................................................18 69 10. Security Considerations..........................................19 70 11. IANA Considerations..............................................21 71 12. ICANN Considerations.............................................21 72 APPENDIX A. Security Transform Formats..............................21 73 13. References.......................................................22 74 14. Acknowledgments..................................................23 75 15. Author's Address.................................................23 76 16. Copyright Statement..............................................24 78 1. Abstract 80 This memo describes the Host Identity Payload (HIP) described in the 81 HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that 82 uses it to establish a rapid authentication between two hosts and 83 continuity between those hosts independent of the Networking Layer. 84 The various forms of the Host Identity, HI, HIT, and LSI are covered 85 in detail and how they support the authentication and the 86 establishment of Keying Material that is used by ESP [ESP]. 88 The basic state machine for HIP provides a HIP compliant host with 89 the resiliency to avoid many DOS attacks. The basic HIP exchange 90 for two public hosts shows the actual packet flow. Other HIP 91 exchanges, including those that work across NATs are covered in the 92 HIP implementation document [HIPIMPL]. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in [RFC-2119]. 100 3. Introduction 102 Moskowitz 2 103 The Host Identity Payload (HIP) along with the HIP Protocol a rapid 104 exchange of Host Identities (HI) that also establishes a Security 105 Association for ESP. The HIP protocol is resistant to Denial-of- 106 Service (DOS) and Man-in-the-middle (MITM) attacks, and when used to 107 enable ESP, provides DOS and MITM protection to TCP and UDP. 109 The Host Identity Payload introduces a new namespace, the Host 110 Identity. There are three representations of the Host Identity, 111 the full Identity (HI), the Host Identity Tag (HIT), and the Local 112 Scope Identity (LSI). Three representations are used, as each meets 113 a different design goal of HIP, and none of them can be removed and 114 meet these goals. The HI is the Identity, normally a public key. 115 Since there are different public key algorithms that can be used 116 with different key lengths, the HI is not good for using as the HIP 117 packet identifier, or as a index into the various operational tables 118 needed to support HIP. 120 A hash of the HI, the Host Identity Tag (HIT) thus becomes the 121 operational representation. It is 128 bits long, and the index in 122 the payload. However, in many environments, 128 bits is still 123 considered large. Also IPv4 is constrained with 32 bit API fields. 124 So the third representation, the LSI is 32 bits. The LSI provides a 125 compression of the HIT with only a local scope so that it can be 126 carried efficiently in any packet and used in API calls. 128 The HIP protocol is only four packets long. The four-packet design 129 helps make HIP DOS attack resilient. The protocol exchanges Diffie- 130 Hellman keys in the 2nd and 3rd packets and starts the cookie 131 exchange in the 2nd packet. The exchange uses the Diffie-Hellman 132 exchange to hide the Host Identities and exchanges these hidden 133 Identities in packets 3 and 4. Data datagrams start after the 4th 134 packet. However, in some cases, the 3rd and 4th HIP packets can 135 carry a datagram. 137 Finally, HIP is designed as an end-to-end authentication and key 138 establishment protocol. It lacks much of the fine-grain policy 139 control found in IKE that allows IKE to support complex gateway 140 policies. Thus HIP is not a complete replacement for IKE. In many 141 cases, particularly in spanning addressing realms, HIP would be the 142 preferred key establishment protocol. 144 4.1. Host Identity 146 The structure of the Host Identity is that of a public key pair. 147 DSA is the MUST implement algorithm for any implementation 148 supporting public keys for the Host Identity. 150 The Host Identity is never directly used in any Internet protocol. 151 It may be stored in various DNS or LDAP directories as identified in 152 the HIP architecture and it is passed in the HIP payload. It SHOULD 153 be stored in a DNS KEY RR with the protocol set to HIP. A Host 154 Identity Tag (HIT) is used in protocols to represent the Host 156 Moskowitz 3 157 Identity. Another representation of the Host Identity, the Local 158 Scope Identity (LSI) can also be used in protocols and APIs. LSI's 159 advantage over HIT is its size; its disadvantage is its local scope. 161 4.2. Host Identity Tag (HIT) 163 The Host Identity Tag is a 128 bit field. There are two advantages 164 of using a hash over the actual Identity in protocols. First its 165 fix length makes for easier protocol coding and also better manages 166 the packet size cost of this technology. Secondly, it presents a 167 consistent format to the protocol whatever underlying identity 168 technology is used. 170 HIT functions much like the SPI does in IPsec. However, instead of 171 being an arbitrary 32-bit value that, in combination with the 172 destination IP address and security protocol (ESP), uniquely 173 identifies the Security Association for a datagram, HIT identifies 174 the public key that can validate the packet authentication. HIT 175 SHOULD be unique in the whole IP universe. If there is more than 176 one public key for a HIT, the HIT acts as a hint for the correct 177 public key to use. 179 There are two formats for HIT. These two formats were selected to 180 avoid the most commonly occurring IPv6 addresses in RFC 2373 181 [RFC2372]. Bits 0 and 1 are used to differentiate the formats. If 182 Bit 0 is zero and Bit 1 is one, then the rest of HIT is a 126 bits 183 of a Hash of the key. For example, if the Identity is DSA, these 184 bits MUST be the least significant 126 bits of the SHA-1 [FIPS-180- 185 1] hash of the DSA public key Host Identity. 187 If Bit 0 is one and Bit 1 is zero, then the next 62 bits is the Host 188 Assigning Authority (HAA) field, and only the last 64 bits come from 189 a SHA-1 hash of the Host Identity. This format for HIT is 190 recommended for 'well known' systems. It is possible to support a 191 resolution mechanism for these names in directories like DNS. 192 Another use of HAA is in policy controls. 194 The birthday paradox sets a bound for the expectation of collisions. 195 It is based on the square root of the number of values. A 64-bit 196 hash, then, would put the chances of a collision at 50-50 with 2^32 197 hosts (4 billion). A 1% chance of collision would occur in a 198 population of 640M and a .001% collision chance in a 20M population. 199 A 128 bit hash will have the same .001% collision chance in a 200 9x10^16 population. 202 Allocation Prefix Fraction of IPv6 203 (binary) Address Space 204 ------------------------ -------- ------------- 206 IPv6 Address space 00 1/4 207 126 bit HIT 01 209 Moskowitz 4 210 HAA assigned 64 bit HIT 10 211 IPv6 Address space 11 1/4 213 4.2.1. Storing HIT in DNS 215 The HIT SHOULD be stored in DNS. The exception to this is anonymous 216 identities. The HIT is stored in a new KEY RR. The HIT KEY RR will 217 have all flags set to ZERO, its protocol set to HIP, and algorithm 218 set to HIT128. The 'public key' field of the HIT KEY RR will be the 219 128 bit HIT. 221 4.3. Host Assigning Authority (HAA) field 223 The 62 bits of HAA supports two levels of delegation. The first is 224 a registered assigning authority (RAA). The second is a registered 225 identity (RI, commonly a company). The RAA is 22 bits with values 226 assign sequentially by ICANN. The RI is 40 bits, also assigned 227 sequentially but by the RAA. This can be used to create a 228 resolution mechanism in the DNS. For example if FOO is RAA number 229 100 and BAR is FOO's 50th registered identity, and if 230 1385D17FC63961F5 is the hash of the key for www.foo.com, then by 231 using DNS Binary Labels [DNSBIN] there could be a reverse lookup 232 record like: 234 \[x1385D17FC63961F5/64].\[x32/40].\[x64/22].HIT.int IN PTR 235 www.foo.com. 237 4.4. Local Scope Identity (LSI) 239 LSIs are 32 bit localized representations of a Host Identity. The 240 purpose of an LSI is to facilitate using Host Identities in existing 241 protocols and APIs. The owner of the Host Identity does not set its 242 own LSI; each host selects its partner's 32 bit representation for a 243 Host Identity. LSI assignment is sequential off of a random 244 starting point. That is, at kernel initiation, a random starting 245 point is selected for LSIs, and they are assigned sequentially 246 thereafter. This avoids collisions if LSIs are assigned 247 sequentially starting from zero, and even collisions on a busy host 248 if assigned randomly. The risk of collisions for random assignment 249 is1% in a population of 10,000. 251 Examples of how LSIs can be used include: as the address in a FTP 252 command and as the address in a socket call. Thus LSIs act as a 253 bridge for Host Identity into old protocols and APIs. 255 4.5. Security Parameter Index (SPI) 257 SPIs are used in ESP to index into the security association 258 negotiated in HIP. The ESP SPIs have added significance when used 260 Moskowitz 5 261 with HIP; they are a compressed representation of the HIT in every 262 packet. Thus they MAY be used by intermediary systems in providing 263 services like address mapping. A system does not set its own SPI; 264 each host selects its partner's SPI. It MUST be random. The risk 265 of collisions is too great (1% in a population of 10,000). 267 A different SPI MUST be used for each HIP exchange with a particular 268 host; this is to avoid a replay attack. Additionally, when a host 269 rekeys, the SPI MUST change. One method for SPI creation that meets 270 these criteria, would be to concatenate the HIT with a 32 bit random 271 number, hash this (using SHA1), and then use the high order 32 bits 272 as the SPI. 274 4.6. Difference between an LSI and the SPI 276 There is a subtle difference between an LSI and a SPI. 278 The LSI is relatively longed lived. A system selects its peer's LSI 279 and SHOULD reuse a previous LSI for a HIT during a HIP exchange. 280 The LSI ONLY appears in the 3rd and 4th HIP packets (each system 281 providing the other with its LSI). The LSI is used anywhere in 282 system processes where IP addresses have traditionally have been 283 used, like in TCBs and FTP port commands. 285 The SPI is short-lived. It changes with each HIP exchange and with 286 a HIP rekey. A system notifies its peer of the SPI to use in ESP 287 packets sent to it. Since the SPI is in all but the first two HIP 288 packets, it can be used in intermediary systems to assist in address 289 remapping. 291 5. The Host Identity Payload 293 The Host Identity Payload or HIP is IP protocol NN. HIP SHOULD be 294 carried in every datagram. However, since HIP datagrams are 295 relatively large (at least 20 bytes), and ESP already has all of the 296 functionality to maintain and protect state, the HIP payload is 297 'compressed' into an ESP payload after the HIP exchange. Thus in 298 practice, HIP packets only occur in datagrams to establish or change 299 HIP state. 301 5.1. HIP format 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Next Header | Payload Len | Type | VER. | RES. | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | Host Identity Tag (HIT) | 310 | | 312 Moskowitz 6 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 | HIP Key payload (opt) | 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ESP followed by IP payload (opt) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Next Header WILL be zero for those HIP packets that do not carry a 323 transport layer. Thus Next Header SHOULD only be zero or 50 (ESP). 325 Payload length is the length, in bytes, of the optional HIP Key 326 payload. It is zero if there is no payload. Thus the length of the 327 HIP envelope is 20 plus the payload length. 329 The Type indicates which HIP packet this is. 331 The HIP Version is one byte. The current version is 1. 333 The HIT is always 128 bits (16 bytes). 335 5.2. HIP Key Payload 337 The HIP Key Payload is used to carry the public key associated with 338 the HIT and related security information. The format of the HIP Key 339 Payload is a simplification of a DNS message [DNS]. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | RCOUNT | FQDNLGTH | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 / FQDN / 348 / / 349 | 0 � 7 bytes padding | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | RDLENGTH | TYPE | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 / RDATA / 355 / / 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 . . 359 . . 360 . . 362 Moskowitz 7 363 RCOUNT is the number of HIP Resource Records. If the sender does 364 not have (or does not wish to divulge) an FQDN, a value of '.' will 365 be used. The sender arbitrarily selects the content of the padding 366 field. 368 The HIP Resource Records will either be a KEY (e.g. DSA and D-H), 369 SIG [DNSSEC], or OPT [EDNS] record. The RDATA of the OPT record in 370 the payload can contain any of the following: 372 OPT Attribute Length Data 374 Remotes_HIT 128 Remote's HIT 375 HIP_COOKIE 192 3 64 bit fields: 376 Random # I, 377 K or random # J, 378 Hash target, Ltrunc(SHA1(I|J)) 379 or Utrunc(SHA1(I|J)) 380 HIP_TRANSFORM variable ISAKMP Transform (Appendix A) 381 Without first 32 bits 382 Using IPsec DOI 383 ESP_TRANSFORM variable ISAKMP Transform (Appendix A) 384 Without first 32 bits 385 Using IPsec DOI 386 Remotes_LSI 32 Remote's LSI 387 Remotes_SPI 32 Remote's SPI 389 5.3. HIP Cookie Exchange 391 The HIP cookie exchange serves to manage the establishment of state 392 between the Initiator and Responder. This cookie exchange is 393 different than other 3-way exchanges in that the Responder starts 394 the exchange. Since the Responder starts the exchange, it can set 395 the difficulty for the Initiator. The Responder supplies a random 396 number I, and requires the Initiator hash it with a random number J. 397 The resulting hash's lowest order K bits MUST match a hash target 398 also supplied by the Responder. To accomplish this, the Initiator 399 will have to generate a number of Js until one produces the hash 400 target; the worst case SHOULD be 2^K hash operations. The Responder 401 needs only hash the Initiator's J with its I to prove that the 402 Initiator did its assigned task. 404 Thus the Responder can set the difficulty for Initiator, based on 405 its concern of trust of the Initiator. 407 6. HIP Packets 409 There are 7 HIP packets. Four are for the HIP exchange and the 410 other three are for mid-state changes (rekeying and address 411 migration). 413 Moskowitz 8 414 6.1. I1 - the HIP Initiator packet 416 Next Header = 0 417 Type = 1 418 HIT = Initiator's HIT 419 Payload Contains: 420 Responder's HIT in a KEY HIT RR 422 The Initiator gets the responder's HIT either from a DNS lookup of 423 the responder's FQDN or from a local table. 425 Since this packet is so easy to spoof even if it were signed, no 426 attempt is made to add to its generation or processing cost. 427 Implementation MUST be able to handle a storm of I1 packets, 428 discarding those with common content that arrive within a small time 429 delta. 431 6.2. R1 - the HIP Responder packet 433 Next Header = 0 434 Type = 2 435 HIT = Responder's HIT 436 Payload Contains: 437 Responder's HI in a KEY RR (e.g. KEY DSA RR) 438 Initiator's HIT in a KEY HIT RR 439 Responder's Diffie-Hellman public value in a KEY DH RR 440 HIP TRANSFORM in a OPT RR 441 ESP TRANSFORM in a OPT RR 442 HIP COOKIE in an OPT RR 443 HIP SIG in a SIG RR 445 If the responder has multiple HIs, the HIT used MUST match 446 Initiator's request. 448 The Diffie-Hellman value is ephemeral, but can be reused over a 449 number of connections. In fact, as a defense against I1 storms, an 450 implementation MAY use the same Diffie-Hellman value for a period of 451 time, for example 15 minutes. By using a small number of Is for a 452 given Diffie-Hellman value, the R1 packets can be pre-computed and 453 delivered as quickly as I1 packets arrive. A scavenger process 454 should clean up unused DHs and Is. 456 The HIP_TRANSFORM contains the encryption algorithms supported by 457 the responder to protect the HI exchange, in order of preference. 459 The ESP_TRANSFORM contains the ESP modes supported by the responder, 460 in order of preference. 462 HIP_COOKIE contains random I, K, and Hash Target. I is an internal 463 pointer to the HI, HIT, and DH sent to the Initiator. It is only 464 used as a pointer until this cookie is used in an SA. K is number 465 of bits that the Initiator must match with the Hash Target. 467 Moskowitz 9 468 The HIP SIG is calculated over the whole HIP envelope. The Initiator 469 MUST validate this SIG. It MAY use either the HI in the packet or 470 the HI from a DNS query. 472 6.3. I2 - the HIP Second Initiator packet 474 Next Header = 0 475 Type = 3 476 HIT = Initiator's HIT 477 Payload Contains: 478 Responder's HIT in a KEY HIT RR 479 HIP COOKIE in an OPT RR 480 Responder's LSI in an OPT RR 481 Responder's SPI in an OPT RR 482 Initiator's Diffie-Hellman public value in a KEY DH RR 483 HIP TRANSFORM in a OPT RR 484 The following Resource Records are encrypted using the HIP 485 Transform and are in a HIP ENCRPYT OPT RR 486 ESP TRANSFORM in a OPT RR 487 Initiator's HI in a KEY RR (e.g. KEY DSA RR) 488 HIP SIG in a SIG RR 490 If the initiator has multiple HIs, the HI and HIT used MUST match 491 Responder's reply. 493 HIP_COOKIE contains random I and J, and Ltrunc(SHA1(I|J)) (that is 494 the low order bits of the SHA1 of I concatenated with J). The low 495 order K bits of Ltrunc(SHA1(I|J)) MUST match the low order K bits of 496 the Hash Target. J is an internal pointer to the HI, HIT, and DH 497 sent to the Responder. 499 The Diffie-Hellman value is ephemeral. A scavenger process should 500 clean up unused DHs and Js. 502 The HIP_TRANSFORM contains the encryption used to protect the HI 503 exchange selected by the initiator. All implementations MUST 504 support the 3DES transform. 506 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 507 All implementations MUST support 3DES-HMAC-SHA-1-96, RFCs 2404 and 508 2451. 510 The HIP SIG is calculated over whole HIP envelope. The Responder 511 MUST validate this SIG. It MAY use either the HI in the packet or 512 the HI from a DNS query. 514 6.4. R2 - the HIP Second Responder packet 516 Next Header = 0 517 Type = 4 519 Moskowitz 10 520 HIT = Responder's HIT 521 Payload Contains: 522 Initiator's LSI in an OPT RR 523 Initiator's SPI in an OPT RR 524 The following Resource Records are encrypted using the HIP 525 Transform and are in a HIP ENCRPYT OPT RR 526 Responder's HI in a KEY RR (e.g. KEY DSA RR) 527 HIP COOKIE in an OPT RR 528 HIP SIG in a SIG RR 530 HIP_COOKIE contains random I, Ltrunc(SHA1(I|J)), and 531 Rtrunc(SHA1(I|J)). 533 The HIP SIG is calculated over whole HIP envelope. The Initiator 534 MUST validate this SIG. 536 6.5. REK - the HIP Rekey Packet 538 During the life of a Security Association established by HIP, one of 539 the hosts may need to rekey. The reason for rekeying might be an 540 approaching sequence number wrap in ESP, or a local policy on use of 541 a key. Rekeying ends the current SA and starts a new one. The 542 Rekey Payload permits a host to change its Diffie-Hellman key and 543 thus the keying material for ESP. The Rekey Packet is a HIP packet 544 with only a Diffie-Hellman RR in the HIP payload. The HIP packet is 545 transported within the ESP to provide authentication and replay 546 protection of the rekeying; there is no next protocol in the HIP 547 packet. Thus the datagram looks like: 549 IP[ESP[HIP(D-H)]] 551 The HIP content is: 553 Next Header = 0 554 Type = 5 555 HIT = Sender's HIT 556 Payload Contains: 557 New Diffie-Hellman public value in a KEY DH RR 559 When a host receives a Rekey Packet, its second from next ESP packet 560 MUST use the KEYMAT generated by the new Kij. The sending host MUST 561 expect at least a sequence number replay window worth of ESP packets 562 using the old Kij. Out of order delivery could result in needing 563 the old Kij after packets start arriving using the new SA's Kij. 564 Once past the rekeying start, the sending host can drop the old SA 565 and its Kij. 567 The first packet sent by the receiving system MUST be a HIP New SPI 568 packet. This packet supplies the new SPI for the rekeying system, 569 which cannot send any packets until it receives this packet. If it 570 does not receive a HIP New SPI packet within a resonable round trip 572 Moskowitz 11 573 delta, it MUST assume it or the HIP Rekey packet was lost and 574 renegotiate HIP as if in a reboot condition. 576 6.6. NES - the HIP New SPI Packet 578 The HIP New SPI Packet serves two functions. First it provides the 579 rekeying system with its new SPI. Additionally, it provides any 580 intermediate system with the mapping of the old SPI to the new. 581 This is important to systems like NATs [HIPIMPL] that use SPIs to 582 maintain address translation state. The new SPI Packet is a HIP 583 packet with only a SPI OPT RR in the HIP payload. The HIP packet is 584 transported within the ESP to provide authentication and replay 585 protection. There MAY be a next protocol of HIP if the receiving 586 host chooses to rekey at this time. Thus the datagram looks like: 588 IP[ESP[HIP(SPI)]] 589 or 590 IP[ESP[HIP(SPI)[HIP(D-H)]]] 592 The HIP content is: 594 Next Header = 0 or NN (HIP's protocol number) 595 Type = 6 596 HIT = Sender's HIT 597 Payload Contains: 598 Rekeyer's new SPI in an OPT RR 599 HIP SIG in a SIG RR 601 Since intermediate systems need this new SPI, this ESP packet MUST 602 NOT be encrypted, that is ESP NULL is used. The rekeying system 603 MUST anticipate this potential deviation from the agreed ESP 604 Transform. It will recognize the packet as one arriving after it 605 sent the HIP Rekey packet and the ESP Next Header will by NN BEFORE 606 it decrypts, and the beginning of the ESP content is recognized as a 607 HIP packet. 609 Intermediate systems that use the SPI will have to inspect ALL ESP 610 packets for a HIP New SPI packet. This is a potential DOS attack 611 against the Intermediate system, as it cannot perform the ESP 612 authentication. Thus the HIP record is signed with the HIP SIG RR 613 for the benefit of the Intermediate systems. A further step against 614 attack for the Intermediate systems is to implement ESP's replay 615 protection of windowing the sequence number. 617 Since this packet CANNOT be encrypted, the sending system MAY choose 618 to send its Rekey packet (if it is rekeying immediately by local 619 policy) in a separate packet using the new SPI and Kij. 620 Alternatively, the sending system COULD use the following datagram 621 to privately rekey: 623 IP[ESP[HIP(SPI)[ESP[HIP(D-H)]]]] 625 Moskowitz 12 626 Where the first ESP header is the ESP NULL that is required by the 627 HIP New SPI packet and the second ESP header uses the negotiated ESP 628 transform as used in a simple HIP rekey packet. 630 6.7. REA - the HIP Readdress Packet 632 During the life of a Security Association established by HIP, one of 633 the hosts may change its IP address. The reason for readdressing 634 might be a PPP reconnect, DHCP new lease, or IPv6 address prefix 635 change. The readdressing event might be from mobility or Internet 636 reconnection. Although HIP enables ESP to be independent of the 637 internetworking layer, there still needs to be a mapping of the LSI 638 and HIT to an IP address. 640 The Readdress Packet permits a host to notify its partners of an 641 address change. The Readdress Packet is a HIP packet with a A or A6 642 RR in the HIP payload. The address RR is included in the HIP 643 payload not for the partner's benefit (which COULD deduce this from 644 the outer IP header), but for benefit of any intermediary systems 645 that are maintaining state between the HIT and the address. If the 646 readdressed host 'knew' that there were no intermediary systems 647 between it and its partners, it COULD remove the address RR here for 648 architectural purity. However, this option would only further 649 complicate the protocol. 651 The HIP packet is transported within the ESP to provide 652 authentication and replay protection; there is no next protocol in 653 the HIP packet. Thus the datagram looks like: 655 IP[ESP[HIP(A|A6)]] 657 The HIP content is: 659 Next Header = 0 660 Type = 7 661 HIT = Sender's HIT 662 Payload Contains: 663 New address in an A or A6 RR 664 HIP SIG in a SIG RR 666 Since intermediate systems need this new address, this ESP packet 667 MUST NOT be encrypted, that is ESP NULL is used. The receiving 668 system MUST anticipate this potential deviation from the agreed ESP 669 Transform. It will recognize the packet as one with the ESP Next 670 Header of NN BEFORE it decrypts, and the beginning of the ESP 671 content is recognized as a HIP packet. 673 Intermediate systems that use the address will have to inspect ALL 674 ESP packets for a HIP Readdress packet. This is a potential Dos 675 attack against the Intermediate system, as it cannot perform the ESP 676 authentication. Thus the HIP record is signed with the HIP SIG RR 677 for the benefit of the Intermediate systems. A further step against 679 Moskowitz 13 680 attack for the Intermediate systems is to implement ESP's replay 681 protection of windowing the sequence number. 683 6.8. BOS - the HIP Bootstrap Packet 685 The HIP content is: 687 Next Header = 0 688 Type = 10 689 HIT = Announcer's HIT 690 Payload Contains: 691 Announcer's HIT in a KEY HIT RR 692 Announcer's HI in a KEY RR (e.g. KEY DSA RR) 693 HIP SIG in a SIG RR 695 In some situations, an initiator may not be able to learn of a 696 responders information from DNS or another repository. Some 697 examples of this is a DHCP and NetBios servers. Thus a packet is 698 needed to provide information that would otherwise be gleaned from a 699 repository. This HIP packet is either self-signed in applications 700 like SoHo, or from a trust anchor in large private or public 701 deployments. This packet SHOULD be broadcasted frequently. 703 6.9. HIP Fragmentation Support 705 A HIP implementation MUST support IP fragmentation/reassembly. HIP 706 packets can get large, and may encounter low MTUs along their routed 707 path. Since HIP does not provide a mechanism to use multiple IP 708 datagrams for a single HIP packet, support of path MTU discovery 709 does not bring any value to HIP. HIP aware NAT systems MUST perform 710 any IP reassembly/fragmentation. 712 7. ESP with HIP 714 HIP sets up a Security Association (SA) to enable ESP in an end-to- 715 end manner that can span addressing realms (i.e. across NATs). This 716 is accomplished through the various informations that are exchanged 717 within HIP. It is anticipated that since HIP is designed for host 718 usage, that is not for gateways, that only ESP transport mode will 719 be supported with HIP. The SA is not bound to an IP address; all 720 internal control of the SA is by the HIT and LSI. Thus a host can 721 easily change its address using Mobile IP, DHCP, PPP, or IPv6 722 readdressing and still maintain the SA. And since the transports 723 are bound to the SA (LSI), any active transport is also maintained. 724 So real world conditions like loss of a PPP connection and its 725 reestablishment or a mobile cell change will not require a HIP 726 negotiation or disruption of transport services. 728 Since HIP does not negotiate any lifetimes, all lifetimes are local 729 policy. The only lifetimes a HIP implementation MUST support are 731 Moskowitz 14 732 sequence number rollover (for replay protection), and SA timeout. 733 An SA times out if no packets are received using that SA. The 734 default timeout value is 15 minutes. Implementations MAY support 735 lifetimes for the various ESP transforms. Note that HIP does not 736 offer any service comparable with IKE's Quick Mode. A Diffie- 737 Hellman calculation is needed for each rekeying. 739 7.1. Security Parameters Index (SPI) 741 The SPIs in ESP provide a simple compression of the HIP data from 742 all packets after the HIP exchange. This does require a per HIT- 743 pair Security Association (and SPI), and a decrease of policy 744 granularity over other KMPs like IKE. 746 When a host rekeys, it gets a new SPI from its partner. 748 7.2. Supported Transforms 750 All HIP implementations MUST support 3DES [3DES] and HMAC-SHA-1-96 751 [HMACSHA1]. If the Initiator does not support any of the transforms 752 offered by the Responder in the R1 HIP packet, it MUST use 3DES and 753 HMAC-SHA-1-96 and state so in the I2 HIP packet. 755 7.3. Sequence Number 757 The Sequence Number field is MANDATORY in ESP. Anti-replay 758 protection MUST be used in an ESP SA established with HIP. 760 This means that each host MUST rekey before its sequence number 761 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 762 one Diffie-Hellman key is changed, that of the rekeying host. Thus 763 if one host rekeys, the other host SHOULD rekey as well. 765 7.4. ESP usage with non-cryptographic HI 767 Even if the Host Identity is not cryptographically based, ESP MUST 768 still be used after the HIP exchange between the two hosts. The HIP 769 TRANSFORM in this case will be left out of the HIP exchange, and the 770 ESP envelope will not have any authentication of encryption. The 771 purpose of using ESP in this situation is to have the SPI (LSI) for 772 associating the packets with the HITs, and the sequence # for replay 773 protection. 775 8. HIP Exchange packet flow 777 A HIP exchange SHOULD be initiated whenever the DNS lookup returns 778 HIP KEY resource records. Since some hosts may choose not to have 779 information in DNS, hosts SHOULD support opportunistic HIP 780 [HIPIMPL]. 782 Moskowitz 15 783 Only Initiator and Responder in common addressing realm (i.e. both 784 public or both private) is shown here. Other packet flow scenarios 785 are covered in the HIP implementation documents. 787 8.1. The HIP Exchange 789 Initiator gets IP address, HI, and HIT of Responder somehow. 790 Hard coded (bad) 791 DNS lookup 792 DNSSEC important 794 I --> DNS (lookup R) 795 I <-- DNS (R's address, HI, and HIT) 796 I1 I --> R (Hi. Here is my I1, let's talk HIP) 797 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 798 I2 I --> R (Compute, compute, here is my counter I2) 799 R2 I <-- R (OK. Let�s finish HIP cookie with my R2) 800 I --> R (ESP protected data) 801 I <-- R (ESP protected data) 803 8.2. HIP KEYMAT 805 HIP keying material is derived from the Diffie-Hellman Kij produced 806 during the HIP exchange. The initiator has Kij during the creation 807 or the I2 packet, and the responder has Kij once it receives the I2 808 packet. This is why I2 can already contain encrypted information. 809 There are four keys that are derived from Kij; these are the 810 initiator and responder HIP keys and the initiator and responder ESP 811 keys. These four keys MUST be drawn sequentially (HIP initiator, 812 HIP responder, ESP initiator, EXP responder, and where the ESP 813 transform requires an encrypting and an authenticating key, they are 814 taken sequentially) from the Kij KEYMAT. For situations where the 815 amount of keying material desired is greater than that supplied by 816 Kij, KEYMAT is expanded by feeding Kij into the following operation: 818 KEYMAT = K1 | K2 | K3 | ... 819 where 821 K1 = SHA2-512(Kij | Resp-SPI) 822 K2 = SHA2-512(K1 | Resp-SPI) 823 K3 = SHA2-512(K2 | Resp-SPI) 824 etc. 826 In the situation where Kij is the result of a HIP rekey exchange, 827 there is only the need from one set of ESP keys. These are then the 828 only keys taken from Kij. 830 8.3. Refusing a HIP exchange 832 Moskowitz 16 833 A HIP aware host may choose not to accept a HIP exchange 834 negotiation. If the host's policy is to only be an initiator, it 835 should begin its own HIP exchange. There is a risk of a race 836 condition if each host's policy is to only be an initiator, at which 837 point the HIP exchange will fail. 839 If the host's policy does not permit it to enter into a HIP exchange 840 with the initiator, it should send an ICMP Host Unreachable, 841 Administratively Prohibited message. A more complex HIP packet is 842 not used here as it actually opens up more potential DOS attacks 843 than a simple ICMP message. 845 8.4. Reboot restart of HIP 847 If a host reboots or times out, it has lost its HIP state. If it is 848 the initiator that loss state it simply restarts the HIP exchange. 849 The responder sends an R1 HIP packet, but does not reset its state 850 until it receives the I2 HIP packet. This is to handle DOS attacks 851 that simulate a reboot of the initiator. 853 If it is the responder that loss state, the recovery is more 854 involved. The initiator would send an ESP packet, the responder 855 will reply with an ICMP Host unreachable, Protocol unreachable. 856 After the initiator receives N such ICMP messages (default is 5; the 857 value of N is an initiator policy), the initiator resets its state 858 with the responder and restarts the HIP exchange. 860 Simulating a responder loss of state is a potential denial of 861 service attack. The initiator can manage this attack by dropping 862 any of the above ICMP messages if a responder ESP packet is received 863 within some reasonable delta after it sent its ESP packet. 865 8.5. Sequence Number State Machine 867 Ioo Initiator at no data packets sent, none received 868 Roo Responder at no data packets sent, none received 869 I1 or R1 Initial HIP packet from Host 870 I2 or R2 Second HIP with data packet from Host 871 IE or RE Data packet from Host with ESP 872 Inm or Rnm host sent packet n, and received packet m 874 +---------+ 875 | Ioo,Roo |<----------------------------+ 876 +---------+ | 877 | | 878 | I1->R | 879 | | 880 v | 881 +---------+ | 883 Moskowitz 17 884 | Ioo,Roo | | 885 +---------+ | 886 | | 887 | R1->I | 888 | | 889 v | After I receives 890 +---------+ | x ICMPs 891 | Ioo,Roo | | 892 +---------+ | 893 | | 894 | I2->R | 895 | | 896 v | 897 +---------+ I2->R +---------+ | 898 | I1o,Ro1 |<-----------| Ioo,Rmn | | 899 +---------+ +---------+ | 900 | ^ | 901 | R2->I | R1->I | 902 | | | 903 v | | 904 +---------+ +---------+ | 905 | I11,R11 | | Ioo,Rmn | | 906 +---------+ +---------+ | +---------+ 907 | ^ | | Inm,Roo |-+ 908 | ESP | I1->R | +---------+ | 909 | Packets | | ^ | 910 v I reboots +---------+ | | Iesp->R | Ricmp 911 +---------+ ---------->| Ioo,Rmn | | | | ->I 912 +->| Inm,Rmn | or timeout +---------+ +---------+ | 913 | +---------+ -------------------------->| Inm,Roo |<---+ 914 | | | ^ R reboots +---------+ 915 |NES | | +------+ or timeout 916 |->R |Rrky|Irky | 917 | |->I |->R |NES 918 | | +----+ |->I 919 | v v | 920 +---------+ +---------+ 921 | In1,R1n | | I1m,Rm1 | {rekeying states} 922 +---------+ +---------+ 924 9. HIP Policies 926 There are a number of variables that will influence the HIP 927 exchanges that each host must support. All HIP implementations MUST 928 support at least 2 HIs, one to publish in DNS and one for anonymous 929 usage. Although anonymous HIs will be rarely used as responder HIs, 930 they will be common for initiators. Support for multiple HIs is 931 recommended. 933 Many initiators would want to use a different HI for different 934 responders. The implementations SHOULD provide for an ACL of 935 initiator HIT to responder HIT. This ACL SHOULD also include 937 Moskowitz 18 938 preferred transform and local lifetimes. For HITs with HAAs, 939 wildcarding SHOULD be supported. Thus if a Community of Interest, 940 like Banking gets an RAA, a single ACL could be used. A global 941 wildcard would represent the general policy to be used. Policy 942 selection would be from most specific to most general. 944 The value of K used in the HIP R1 packet can also vary by policy. K 945 should never be greater than 8, but for trusted partners it could be 946 as low as 1. 948 Responders would need a similar ACL, representing which hosts they 949 accept HIP exchanges, and the preferred transform and local 950 lifetimes. Wildcarding SHOULD be support supported for this ACL 951 also. 953 10. Security Considerations 955 HIP is designed to provide secure authentication of hosts and 956 provide a fast key exchange for IPsec ESP. HIP also attempts to 957 limit the exposure of the host to various denial-of-service and man- 958 in-the-middle attacks. In so doing, HIP itself is subject to its 959 own DOS and MITM attacks that potentially could be more damaging to 960 a host's ability to conduct business as usual. 962 The Security Association for ESP is indexed by the LSI-SPI, not the 963 SPI and IP address. HIP enabled ESP is IP address independent. 964 This might seem to make it easier for an attacker, but ESP with 965 replay protection is already as well protected as possible, and the 966 removal of the IP address as a check should not increase the 967 exposure of ESP to DOS attacks. 969 Denial-of-service attacks take advantage of the cost of start of 970 state for a protocol on the responder compared to the 'cheapness' on 971 the initiator. HIP makes no attempt to increase the cost of the 972 start of state on the initiator, but makes an effort to reduce the 973 cost to the responder. This is done by having the responder start 974 the 3-way cookie exchange instead of the initiator, making the HIP 975 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 976 packet that the responder MAY use many times. The duration of use 977 is a paranoia versus throughput concern. Using the same Diffie- 978 Hellman values, I and Hash target has some risk. This risk needs to 979 be balanced against a potential storm of HIP I1 packets. 981 This shifting of the start of state cost to the initiator in 982 creating the I2 HIP packet, presents another DOS attack. The 983 attacker spoofs the I1 HIP packet and the responder sends out the R1 984 HIP packet. This could conceivably tie up the 'initiator' with 985 evaluating the R1 HIP packet, and creating the I2 HIP packet. The 986 defense against this attack is to simply ignore any R1 packet where 987 a corresponding I1 was not sent. 989 Moskowitz 19 990 A second form of DOS attack arrives in the I2 HIP packet. Once and 991 attacking initiator has solved the cookie challenge, it can send 992 packets with spoofed IP source addresses with either invalid 993 encrypted HIP payload component or a bad HIP SIG. This would take 994 resources in the responder�s part to reach the point to discover 995 that the I2 packet cannot be completely processed. The defense 996 against this attack is after N bad I2 packets, the responder would 997 discard any I2s that contain the given I. Sort of a shutdown on the 998 attack. The attacker would have to request another R1 and use that 999 to launch a new attack. The responder could up the value of K while 1000 under attack. On the downside, valid I2s might get dropped too. 1002 A third form of DOS attack is emulating the restart of state after a 1003 reboot of one of the partners. To protect against such an attack on 1004 the responder, it should send reply to an I1 HIP packet without 1005 resetting its state. Only on receipt of an I2 HIP packet within a 1006 reasonable delta after sending its R1 HIP packet, should the 1007 responder reset its state. An initiator protects itself be ignoring 1008 any R1 or R2 packets while it has state with R. 1010 A fourth form of DOS attack is emulating the end of state. HIP has 1011 no end of state packet. It relies on a local policy timer to end 1012 state. 1014 Man-in-the-middle attacks are difficult to defend against, without 1015 third-party authentication. A skillful MITM could easily handle all 1016 parts of HIP; but HIP indirectly provides the following protection 1017 from a MITM attack. If the responder's HI is retrieved from a 1018 signed DNS zone by the initiator, the initiator can use this to 1019 validate the R1 HIP packet. 1021 Likewise, if the initiator's HI is in a secure DNS zone, the 1022 responder can retrieve it after it gets the I2 HIP packet and 1023 validate that. However, since an initiator may choose to use an 1024 anonymous HI, it knowingly risks a MITM attack. The responder may 1025 choose not to accept a HIP exchange with an anonymous initiator. 1027 Since not all hosts will ever support HIP, ICMP 'Destination 1028 Protocol Unreachable' are to be expected and present a DOS attack. 1029 Against an initiator, the attack would look like the responder does 1030 not support HIP, but shortly after receiving the ICMP message, the 1031 initiator would receive a valid R1 HIP packet. Thus to protect 1032 against this attack, an initiator should not react to an ICMP 1033 message until a reasonable delta time to get the real responder's R1 1034 HIP packet. A similar attack against the responder is more 1035 involved. First an ICMP message is expected if the I1 was a DOS 1036 attack and the real owner of the spoofed IP address does not support 1037 HIP. The responder SHOULD NOT act on this ICMP message to remove 1038 the minimal state from the R1 HIP packet, but wait for either a 1039 valid I2 HIP packet or the natural timeout of the R1 HIP packet. 1040 This is to allow for a sophisticated attacker that is trying to 1041 break up the HIP exchange. Likewise, the initiator should ignore 1043 Moskowitz 20 1044 any ICMP message while waiting for an R2 HIP packet, deleting state 1045 only after a natural timeout. 1047 Another MITM attack is simulating a responder's rejection of a HIP 1048 initiation. This is a simple ICMP Host Unreachable, 1049 Administratively Prohibited message. A HIP packet was not used 1050 because it would either have to have unique content, and thus 1051 difficult to generate, resulting in yet another DOS attack, or just 1052 as spoofable as the ICMP message. The defense against this MITM 1053 attack is for the responder to wait a reasonable time period to get 1054 a valid R1 HIP packet. If one does not come, then the Initiator has 1055 to assume that the ICMP message is valid. Since this is the only 1056 point in the HIP exchange where this ICMP message is appropriate, it 1057 can be ignored at any other point in the exchange. 1059 11. IANA Considerations 1061 IANA has assigned Protocol number XX to HIP. 1063 A new KEY RR protocol of XX is assigned to HIP and an algorithm of 1064 XX is assigned to HIT128. 1066 IANA will has also assigned new DNS OPT resource record OPTION-CODES 1067 of Remotes_HIT [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and 1068 Remotes_LSI [x]. 1070 12. ICANN Considerations 1072 ICANN are covered in the HIP Architecture [HIPARCH] document. 1074 APPENDIX A. Security Transform Formats 1076 The security transforms, HIP and ESP transforms, use the format from 1077 ISAKMP [ISAKMP]. 1079 0 1 2 3 1080 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 1081 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 / | NP = Transform| RESERVED | Payload Length | 1083 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Tr1| Transform # 1 | Transform ID | RESERVED2 | 1085 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 \ | SA Attributes | 1087 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 / | NP = 0 | RESERVED | Payload Length | 1089 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Tr2| Transform # 2 | Transform ID | RESERVED2 | 1091 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 \ | SA Attributes | 1093 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Moskowitz 21 1096 Transform Classes Values 1098 HIP_ENC 1 1099 ESP_ENC 2 1100 ESP_AUTH 3 1102 HIP Encryption Algorithm Values 1104 DES-CBC 1 1105 IDEA-CBC 2 1106 Blowfish-CBC 3 1107 RC5-R16-B64-CBC 4 1108 3DES-CBC 5 1109 CAST-CBC 6 1111 ESP Encryption Algorithm Value 1113 RESERVED 0 1114 ESP_DES_IV64 1 1115 ESP_DES 2 1116 ESP_3DES 3 1117 ESP_RC5 4 1118 ESP_IDEA 5 1119 ESP_CAST 6 1120 ESP_BLOWFISH 7 1121 ESP_3IDEA 8 1122 ESP_DES_IV32 9 1123 ESP_RC4 10 1124 ESP_NULL 11 1126 ESP Authenticat Algorithm Value 1128 RESERVED 0-1 1129 MD5 2 1130 SHA 3 1131 DES 4 1133 13. References 1135 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", RFC 2119, March 1997. 1138 [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", 1139 draft-ietf-moskowitz-hip-arch-03.txt, January 2001. 1141 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 1142 draft-ietf-moskowitz-hip-impl-02.txt, January 2001. 1144 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 1145 Payload", RFC 2406, November 1998. 1147 Moskowitz 22 1149 [RFC2373], R. Hinden, S. Deering., "IP Version 6 Addressing 1150 Architecture", RFC 2373, July 1998. 1152 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1153 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 1154 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 1156 [DNS], Mockapetris, P., "Domain Names - Implementation And 1157 Specification", RFC 1035, November 1987. 1159 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 1160 RFC 2535, March 1999. 1162 [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 1163 1998. 1165 [3DES], Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 1166 Algorithms", RFC 2451, November 1998. 1168 [HMACSHA1], Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within 1169 ESP and AH", RFC 2404, November 1998. 1171 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1172 "Internet Security Association and Key Management Protocol", RFC 1173 2408, November 1998. 1175 14. Acknowledgments 1177 The drive to create HIP came to being after attending the MALLOC 1178 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave me 1179 the assist to get HIP beyond 5 paragraphs of ideas. It has matured 1180 considerably since the early drafts thanks to extensive input from 1181 IETFers. Most importantly, its design goals are articulated and are 1182 different from other efforts in this direction. Particular mention 1183 goes to the members of the NameSpace Research Group of the IRTF. 1184 Noel Chiappa provided the framework for LSIs and Kieth Moore the 1185 impetuous to provide resolvability. Steve Deering provided 1186 encouragement to keep working, as a solid proposal can act as a 1187 proof of ideas for a research group. 1189 Many others contributed; extensive security tips were provided by 1190 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 1191 Kocher taught me how to make the cookie exchange expensive for the 1192 Initiator to respond, but easy for the Responder to validate. 1193 Rodney Thayer and Hugh Daniels provide extensive feedback. John 1194 Gilmore kept me challenged to provide something of value. I hope I 1195 have. 1197 15. Author's Address 1199 Robert Moskowitz 1201 Moskowitz 23 1202 TruSecure Corporation 1203 1200 Walnut Bottom Rd. 1204 Carlisle, PA 17013 1205 Email: rgm@trusecure.com 1207 16. Copyright Statement 1209 Copyright (c) The Internet Society (2001). All Rights Reserved. 1210 This document and translations of it may be copied and furnished to 1211 others, and derivative works that comment on or otherwise explain it 1212 or assist in its implementation may be prepared, copied, published 1213 and distributed, in whole or in part, without restriction of any 1214 kind, provided that the above copyright notice and this paragraph 1215 are included on all such copies and derivative works. However, this 1216 document itself may not be modified in any way, such as by removing 1217 the copyright notice or references to the Internet Society or other 1218 Internet organizations, except as needed for the purpose of 1219 developing Internet standards in which case the procedures for 1220 copyrights defined in the Internet Standards process must be 1221 followed, or as required to translate it into languages other than 1222 English. 1224 The limited permissions granted above are perpetual and will not be 1225 revoked by the Internet Society or its successors or assigns. 1227 This document and the information contained herein is provided on an 1228 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1229 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1230 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1231 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1232 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1234 Moskowitz 24