idnits 2.17.1 draft-moskowitz-hip-03.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 is 1 instance 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 1 longer page, the longest (page 1) being 649 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 732 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 (February 2001) is 8464 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) -- 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 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** 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) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Moskowitz, ICSA Labs 3 Internet Draft 5 Document: February 2001 7 Host Identity Payload 9 And Protocol 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Table of Contents 34 1. Abstract...........................................................2 35 2. Conventions used in this document..................................2 36 3. Introduction.......................................................2 37 4. The Host Identity Payload..........................................3 38 4.1. HIP format.......................................................3 39 4.2. HIP Key Payload..................................................4 40 5. HIP Cookie Exchange................................................5 41 6. HIP Packets........................................................5 42 6.1. I1 - the HIP Initiator packet....................................6 43 6.2. R1 - the HIP Responder packet....................................6 44 6.3. I2 - the HIP Second Initiator packet.............................7 45 6.4. R2 - the HIP Second Responder packet.............................7 46 6.5. REK - the HIP Rekey Packet.......................................8 47 6.6. NES - the HIP New SPI Packet.....................................9 48 6.7. REA - the HIP Readdress Packet..................................10 49 6.8. HIP Fragmentation Support.......................................11 50 7. ESP with HIP......................................................11 51 7.1. Security Parameters Index (SPI).................................11 52 7.2. Supported Transforms............................................11 54 Moskowitz 1 56 Host Identity Payload February 2001 58 7.3. Sequence Number.................................................12 59 7.4. ESP usage with non-cryptographic HI.............................12 60 8. HIP Exchange packet flow..........................................12 61 8.1. The HIP Exchange................................................12 62 8.2. HIP KEYMAT......................................................12 63 8.3. Refusing a HIP exchange.........................................13 64 8.4. Reboot restart of HIP...........................................13 65 8.5. Sequence Number State Machine...................................14 66 9. HIP Policies......................................................15 67 10. Security Considerations..........................................15 68 11. IANA Considerations..............................................17 69 12. ICANN Considerations.............................................17 70 13. References.......................................................17 71 14. Acknowledgments..................................................18 72 15. Author's Address.................................................18 73 16. Copyright Statement..............................................19 75 1. Abstract 77 This memo describes the Host Identity Payload (HIP) described in the 78 HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that 79 uses it to establish a rapid authentication between two hosts and 80 continuity between those hosts independent of the Networking Layer. 81 The various forms of the Host Identity, HI, HIT, and LSI are covered 82 in detail and how they support the authentication and the 83 establishment of Keying Material that is used by ESP [ESP]. 85 The basic state machine for HIP provides a HIP compliant host with 86 the resiliency to avoid many DOS attacks. The basic HIP exchange 87 for two public hosts shows the actual packet flow. Other HIP 88 exchanges, including those that work across NATs are covered in the 89 HIP implementation document [HIPIMPL]. 91 2. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in [RFC-2119]. 97 3. Introduction 99 The Host Identity Payload (HIP) along with the HIP Protocol a rapid 100 exchange of Host Identities (HI) that also establishes a Security 101 Association for ESP. The HIP protocol is resistant to Denial-of- 102 Service (DOS) and Man-in-the-middle (MITM) attacks, and when used to 103 enable ESP, provides DOS and MITM protection to TCP and UDP. 105 The Host Identity Payload introduces a new namespace, the Host 106 Identity. There are three representations of the Host Identity, 107 the full Identity (HI), the Host Identity Tag (HIT), and the Local 109 Moskowitz 2 111 Host Identity Payload February 2001 113 Scope Identity (LSI). Three representations are used, as each meets 114 a different design goal of HIP, and none of them can be removed and 115 meet these goals. The HI is the Identity, normally a public key. 116 Since there are different public key algorithms that can be used 117 with different key lengths, the HI is not good for using as the HIP 118 packet identifier, or as a index into the various operational tables 119 needed to support HIP. 121 A hash of the HI, the Host Identity Tag (HIT) thus becomes the 122 operational representation. It is 128 bits long, and the index in 123 the payload. However, in many environments, 128 bits is still 124 considered large. Also IPv4 is constrained with 32 bit API fields. 125 So the third representation, the LSI is 32 bits. The LSI provides a 126 compression of the HIT with only a local scope so that it can be 127 carried efficiently in any packet and used in API calls. 129 The HIP protocol is only four packets long. The four-packet design 130 helps make HIP DOS attack resilient. The protocol exchanges Diffie- 131 Hellman keys in the 2nd and 3rd packets and starts the cookie 132 exchange in the 2nd packet. The exchange uses the Diffie-Hellman 133 exchange to hide the Host Identities and exchanges these hidden 134 Identities in packets 3 and 4. Data datagrams start after the 4th 135 packet. 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. The Host Identity Payload 146 The Host Identity Payload or HIP is IP protocol NN. HIP SHOULD be 147 carried in every datagram. However, since HIP datagrams are 148 relatively large (at least 20 bytes), and ESP already has all of the 149 functionality to maintain and protect state, the HIP payload is 150 'compressed' into an ESP payload after the HIP exchange. Thus in 151 practice, HIP packets only occur in datagrams to establish or change 152 HIP state. 154 4.1. HIP format 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Header | Payload Len | Type | VER. | RES. | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 | Host Identity Tag (HIT) | 163 | | 165 Moskowitz 3 167 Host Identity Payload February 2001 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 | HIP Key payload (opt) | 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | ESP followed by IP payload (opt) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Next Header WILL be zero for those HIP packets that do not carry a 179 transport layer. Thus Next Header SHOULD only be zero or 50 (ESP). 181 Payload length is the length, in bytes, of the optional HIP Key 182 payload. It is zero if there is no payload. Thus the length of the 183 HIP envelope is 20 plus the payload length. 185 The Type indicates which HIP packet this is. 187 The HIP Version is one byte. The current version is 1. 189 The HIT is always 128 bits (16 bytes). 191 4.2. HIP Key Payload 193 The HIP Key Payload is used to carry the public key associated with 194 the HIT and related security information. The format of the HIP Key 195 Payload is a simplification of a DNS message [DNS]. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | RCOUNT | FQDNLGTH | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 / FQDN / 204 / / 205 | 0 - 7 bytes padding | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | RDLENGTH | TYPE | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 / RDATA / 211 / / 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 . . 215 . . 216 . . 218 Moskowitz 4 220 Host Identity Payload February 2001 222 RCOUNT is the number of HIP Resource Records. If the sender does 223 not have (or does not wish to divulge) an FQDN, a value of '.' will 224 be used. The sender arbitrarily selects the content of the padding 225 field. 227 The HIP Resource Records will either be a KEY (e.g. DSA and D-H), 228 SIG [DNSSEC], or OPT [EDNS] record. The RDATA of the OPT record in 229 the payload can contain any of the following: 231 OPT Attribute Length Data 233 Remotes_HIT 128 Remote's HIT 234 HIP_COOKIE 192 3 64 bit fields: 235 Random # I, 236 K or random # J, 237 Hash target, Ltrunc(SHA1(I|J)) 238 or Utrunc(SHA1(I|J)) 239 HIP_TRANSFORM variable ISAKMP Transform [ISAKMP] 240 Without first 32 bits 241 Using Ipsec DOI 242 ESP_TRANSFORM variable ISAKMP Transform [ISAKMP] 243 Without first 32 bits 244 Using Ipsec DOI 245 Remotes_LSI 32 Remote's LSI 246 Remotes_SPI 32 Remote's SPI 248 5. HIP Cookie Exchange 250 The HIP cookie exchange serves to manage the establishment of state 251 between the Initiator and Responder. This cookie exchange is 252 different than other 3-way exchanges in that the Responder starts 253 the exchange. Since the Responder starts the exchange, it can set 254 the difficulty for the Initiator. The Responder supplies a random 255 number I, and requires the Initiator hash it with a random number J. 256 The resulting hash's lowest order K bits MUST match a hash target 257 also supplied by the Responder. To accomplish this, the Initiator 258 will have to generate a number of Js until one produces the hash 259 target; the worst case SHOULD be 2^K hash operations. The Responder 260 needs only hash the Initiator's J with its I to prove that the 261 Initiator did its assigned task. 263 Thus the Responder can set the difficulty for Initiator, based on 264 its concern of trust of the Initiator. 266 6. HIP Packets 268 There are 7 HIP packets. Four are for the HIP exchange and the 269 other three are for mid-state changes (rekeying and address 270 migration). 272 Moskowitz 5 274 Host Identity Payload February 2001 276 6.1. I1 - the HIP Initiator packet 278 Next Header = 0 279 Type = 1 280 HIT = Initiator's HIT 281 Payload Contains: 282 Responder's HIT in a KEY HIT RR 284 The Initiator gets the responder's HIT either from a DNS lookup of 285 the responder's FQDN or from a local table. 287 Since this packet is so easy to spoof even if it were signed, no 288 attempt is made to add to its generation or processing cost. 289 Implementation MUST be able to handle a storm of I1 packets, 290 discarding those with common content that arrive within a small time 291 delta. 293 6.2. R1 - the HIP Responder packet 295 Next Header = 0 296 Type = 2 297 HIT = Responder's HIT 298 Payload Contains: 299 Responder's HI in a KEY RR (e.g. KEY DSA RR) 300 Initiator's HIT in a KEY HIT RR 301 Responder's Diffie-Hellman public value in a KEY DH RR 302 HIP TRANSFORM in a OPT RR 303 ESP TRANSFORM in a OPT RR 304 HIP COOKIE in an OPT RR 305 HIP SIG in a SIG RR 307 If the responder has multiple HIs, the HIT used MUST match 308 Initiator's request. 310 The Diffie-Hellman value is ephemeral, but can be reused over a 311 number of connections. In fact, as a defense against I1 storms, an 312 implementation MAY use the same Diffie-Hellman value for a period of 313 time, for example 15 minutes. By using a small number of Is for a 314 given Diffie-Hellman value, the R1 packets can be pre-computed and 315 delivered as quickly as I1 packets arrive. A scavenger process 316 should clean up unused DHs and Is. 318 The HIP_TRANSFORM contains the encryption algorithms supported by 319 the responder to protect the HI exchange, in order of preference. 321 The ESP_TRANSFORM contains the ESP modes supported by the responder, 322 in order of preference. 324 HIP_COOKIE contains random I, K, and Hash Target. I is an internal 325 pointer to the HI, HIT, and DH sent to the Initiator. It is only 326 used as a pointer until this cookie is used in an SA. K is number 327 of bits that the Initiator must match with the Hash Target. 329 Moskowitz 6 331 Host Identity Payload February 2001 333 The HIP SIG is calculated over the whole HIP envelope. The Initiator 334 MUST validate this SIG. It MAY use either the HI in the packet or 335 the HI from a DNS query. 337 6.3. I2 - the HIP Second Initiator packet 339 Next Header = 0 340 Type = 3 341 HIT = Initiator's HIT 342 Payload Contains: 343 Responder's HIT in a KEY HIT RR 344 Responder's LSI in an OPT RR 345 Responder's SPI in an OPT RR 346 Initiator's Diffie-Hellman public value in a KEY DH RR 347 HIP TRANSFORM in a OPT RR 348 The following Resource Records are encrypted using the HIP 349 Transform and are in a HIP ENCRPYT OPT RR 350 HIP COOKIE in an OPT RR 351 ESP TRANSFORM in a OPT RR 352 Initiator's HI in a KEY RR (e.g. KEY DSA RR) 353 HIP SIG in a SIG RR 355 If the initiator has multiple HIs, the HI and HIT used MUST match 356 Responder's reply. 358 The Diffie-Hellman value is ephemeral. A scavenger process should 359 clean up unused DHs and Js. 361 The HIP_TRANSFORM contains the encryptions to protect the HI 362 exchange selected by the initiator. 364 HIP_COOKIE contains random I and J, and Ltrunc(SHA1(I|J)) (that is 365 the low order bits of the SHA1 of I concatenated with J). The low 366 order K bits of Ltrunc(SHA1(I|J)) MUST match the low order K bits of 367 the Hash Target. J is an internal pointer to the HI, HIT, and DH 368 sent to the Responder. 370 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 372 The HIP SIG is calculated over whole HIP envelope. The Responder 373 MUST validate this SIG. It MAY use either the HI in the packet or 374 the HI from a DNS query. 376 6.4. R2 - the HIP Second Responder packet 378 Next Header = 0 379 Type = 4 380 HIT = Responder's HIT 381 Payload Contains: 382 Initiator's LSI in an OPT RR 384 Moskowitz 7 386 Host Identity Payload February 2001 388 Initiator's SPI in an OPT RR 389 The following Resource Records are encrypted using the HIP 390 Transform and are in a HIP ENCRPYT OPT RR 391 Responder's HI in a KEY RR (e.g. KEY DSA RR) 392 HIP COOKIE in an OPT RR 393 HIP SIG in a SIG RR 395 HIP_COOKIE contains random I, Ltrunc(SHA1(I|J)), and 396 Rtrunc(SHA1(I|J)). 398 The HIP SIG is calculated over whole HIP envelope. The Initiator 399 MUST validate this SIG. 401 6.5. REK - the HIP Rekey Packet 403 During the life of a Security Association established by HIP, one of 404 the hosts may need to rekey. The reason for rekeying might be an 405 approaching sequence number wrap in ESP, or a local policy on use of 406 a key. Rekeying ends the current SA and starts a new one. The 407 Rekey Payload permits a host to change its Diffie-Hellman key and 408 thus the keying material for ESP. The Rekey Packet is a HIP packet 409 with only a Diffie-Hellman RR in the HIP payload. The HIP packet is 410 transported within the ESP to provide authentication and replay 411 protection of the rekeying; there is no next protocol in the HIP 412 packet. Thus the datagram looks like: 414 IP[ESP[HIP(D-H)]] 416 The HIP content is: 418 Next Header = 0 419 Type = 5 420 HIT = Sender's HIT 421 Payload Contains: 422 New Diffie-Hellman public value in a KEY DH RR 424 When a host receives a Rekey Packet, its second from next ESP packet 425 MUST use the KEYMAT generated by the new Kij. The sending host MUST 426 expect at least a sequence number replay window worth of ESP packets 427 using the old Kij. Out of order delivery could result in needing 428 the old Kij after packets start arriving using the new SA's Kij. 429 Once past the rekeying start, the sending host can drop the old SA 430 and its Kij. 432 The first packet sent by the receiving system MUST be a HIP New SPI 433 packet. This packet supplies the new SPI for the rekeying system, 434 which cannot send any packets until it receives this packet. If it 435 does not receive a HIP New SPI packet within a resonable round trip 436 delta, it MUST assume it or the HIP Rekey packet was lost and 437 renegotiate HIP as if in a reboot condition. 439 Moskowitz 8 440 Host Identity Payload February 2001 442 6.6. NES - the HIP New SPI Packet 444 The HIP New SPI Packet serves two functions. First it provides the 445 rekeying system with its new SPI. Additionally, it provides any 446 intermediate system with the mapping of the old SPI to the new. 447 This is important to systems like NATs [HIPIMPL] that use SPIs to 448 maintain address translation state. The new SPI Packet is a HIP 449 packet with only a SPI OPT RR in the HIP payload. The HIP packet is 450 transported within the ESP to provide authentication and replay 451 protection. There MAY be a next protocol of HIP if the receiving 452 host chooses to rekey at this time. Thus the datagram looks like: 454 IP[ESP[HIP(SPI)]] 455 or 456 IP[ESP[HIP(SPI)[HIP(D-H)]]] 458 The HIP content is: 460 Next Header = 0 or NN (HIP's protocol number) 461 Type = 6 462 HIT = Sender's HIT 463 Payload Contains: 464 Rekeyer's new SPI in an OPT RR 465 HIP SIG in a SIG RR 467 Since intermediate systems need this new SPI, this ESP packet MUST 468 NOT be encrypted, that is ESP NULL is used. The rekeying system 469 MUST anticipate this potential deviation from the agreed ESP 470 Transform. It will recognize the packet as one arriving after it 471 sent the HIP Rekey packet and the ESP Next Header will by NN BEFORE 472 it decrypts, and the beginning of the ESP content is recognized as a 473 HIP packet. 475 Intermediate systems that use the SPI will have to inspect ALL ESP 476 packets for a HIP New SPI packet. This is a potential DOS attack 477 against the Intermediate system, as it cannot perform the ESP 478 authentication. Thus the HIP record is signed with the HIP SIG RR 479 for the benefit of the Intermediate systems. A further step against 480 attack for the Intermediate systems is to implement ESP's replay 481 protection of windowing the sequence number. 483 Since this packet CANNOT be encrypted, the sending system MAY choose 484 to send its Rekey packet (if it is rekeying immediately by local 485 policy) in a separate packet using the new SPI and Kij. 486 Alternatively, the sending system COULD use the following datagram 487 to privately rekey: 489 IP[ESP[HIP(SPI)[ESP[HIP(D-H)]]]] 491 Where the first ESP header is the ESP NULL that is required by the 492 HIP New SPI packet and the second ESP header uses the negotiated ESP 493 transform as used in a simple HIP rekey packet. 495 Moskowitz 9 497 Host Identity Payload February 2001 499 6.7. REA - the HIP Readdress Packet 501 During the life of a Security Association established by HIP, one of 502 the hosts may change its IP address. The reason for readdressing 503 might be a PPP reconnect, DHCP new lease, or IPv6 address prefix 504 change. The readdressing event might be from mobility or Internet 505 reconnection. Although HIP enables ESP to be independent of the 506 internetworking layer, there still needs to be a mapping of the LSI 507 and HIT to an IP address. 509 The Readdress Packet permits a host to notify its partners of an 510 address change. The Readdress Packet is a HIP packet with a A or A6 511 RR in the HIP payload. The address RR is included in the HIP 512 payload not for the partner's benefit (which COULD deduce this from 513 the outer IP header), but for benefit of any intermediary systems 514 that are maintaining state between the HIT and the address. If the 515 readdressed host 'knew' that there were no intermediary systems 516 between it and its partners, it COULD remove the address RR here for 517 architectural purity. However, this option would only further 518 complicate the protocol. 520 The HIP packet is transported within the ESP to provide 521 authentication and replay protection; there is no next protocol in 522 the HIP packet. Thus the datagram looks like: 524 IP[ESP[HIP(A|A6)]] 526 The HIP content is: 528 Next Header = 0 529 Type = 7 530 HIT = Sender's HIT 531 Payload Contains: 532 New address in an A or A6 RR 533 HIP SIG in a SIG RR 535 Since intermediate systems need this new address, this ESP packet 536 MUST NOT be encrypted, that is ESP NULL is used. The receiving 537 system MUST anticipate this potential deviation from the agreed ESP 538 Transform. It will recognize the packet as one with the ESP Next 539 Header of NN BEFORE it decrypts, and the beginning of the ESP 540 content is recognized as a HIP packet. 542 Intermediate systems that use the address will have to inspect ALL 543 ESP packets for a HIP Readdress packet. This is a potential Dos 544 attack against the Intermediate system, as it cannot perform the ESP 545 authentication. Thus the HIP record is signed with the HIP SIG RR 546 for the benefit of the Intermediate systems. A further step against 547 attack for the Intermediate systems is to implement ESP's replay 548 protection of windowing the sequence number. 550 Moskowitz 10 552 Host Identity Payload February 2001 554 6.8. HIP Fragmentation Support 556 A HIP implementation MUST support IP fragmentation/reassembly. HIP 557 packets can get large, and may encounter low MTUs along their routed 558 path. Since HIP does not provide a mechanism to use multiple IP 559 datagrams for a single HIP packet, support of path MTU discovery 560 does not bring any value to HIP. HIP aware NAT systems MUST perform 561 any IP reassembly/fragmentation. 563 7. ESP with HIP 565 HIP sets up a Security Association (SA) to enable ESP in an end-to- 566 end manner that can span addressing realms (i.e. across NATs). This 567 is accomplished through the various informations that are exchanged 568 within HIP. It is anticipated that since HIP is designed for host 569 usage, that is not for gateways, that only ESP transport mode will 570 be supported with HIP. The SA is not bound to an IP address; all 571 internal control of the SA is by the HIT and LSI. Thus a host can 572 easily change its address using Mobile IP, DHCP, PPP, or IPv6 573 readdressing and still maintain the SA. And since the transports 574 are bound to the SA (LSI), any active transport is also maintained. 575 So real world conditions like loss of a PPP connection and its 576 reestablishment or a mobile cell change will not require a HIP 577 negotiation or disruption of transport services. 579 Since HIP does not negotiate any lifetimes, all lifetimes are local 580 policy. The only lifetimes a HIP implementation MUST support are 581 sequence number rollover (for replay protection), and SA timeout. 582 An SA times out if no packets are received using that SA. The 583 default timeout value is 15 minutes. Implementations MAY support 584 lifetimes for the various ESP transforms. Note that HIP does not 585 offer any service comparable with IKE's Quick Mode. A Diffie- 586 Hellman calculation is needed for each rekeying. 588 7.1. Security Parameters Index (SPI) 590 The SPIs in ESP provide a simple compression of the HIP data from 591 all packets after the HIP exchange. This does require a per HIT- 592 pair Security Association (and SPI), and a decrease of policy 593 granularity over other KMPs like IKE. 595 When a host rekeys, it gets a new SPI from its partner. 597 7.2. Supported Transforms 599 All HIP implementations MUST support 3DES [3DES] and HMAC-SHA-1-96 600 [HMACSHA1]. If the Initiator does not support any of the transforms 601 offered by the Responder in the R1 HIP packet, it MUST use 3DES and 602 HMAC-SHA-1-96 and state so in the I2 HIP packet. 604 Moskowitz 11 606 Host Identity Payload February 2001 608 7.3. Sequence Number 610 The Sequence Number field is MANDATORY in ESP. Anti-replay 611 protection MUST be used in an ESP SA established with HIP. 613 This means that each host MUST rekey before its sequence number 614 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 615 one Diffie-Hellman key is changed, that of the rekeying host. Thus 616 if one host rekeys, the other host SHOULD rekey as well. 618 7.4. ESP usage with non-cryptographic HI 620 Even if the Host Identity is not cryptographically based, ESP MUST 621 still be used after the HIP exchange between the two hosts. The HIP 622 TRANSFORM in this case will be left out of the HIP exchange, and the 623 ESP envelope will not have any authentication of encryption. The 624 purpose of using ESP in this situation is to have the SPI (LSI) for 625 associating the packets with the HITs, and the sequence # for replay 626 protection. 628 8. HIP Exchange packet flow 630 A HIP exchange SHOULD be initiated whenever the DNS lookup returns 631 HIP KEY resource records. Since some hosts may choose not to have 632 information in DNS, hosts SHOULD support opportunistic HIP 633 [HIPIMPL]. 635 Only Initiator and Responder in common addressing realm (i.e. both 636 public or both private) is shown here. Other packet flow scenarios 637 are covered in the HIP implementation documents. 639 8.1. The HIP Exchange 641 Initiator gets IP address, HI, and HIT of Responder somehow. 642 Hard coded (bad) 643 DNS lookup 644 DNSSEC important 646 I --> DNS (lookup R) 647 I <-- DNS (R's address, HI, and HIT) 648 I1 I --> R (Hi. Here is my I1, let's talk HIP) 649 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 650 I2 I --> R (Compute, compute, here is my counter I2) 651 R2 I <-- R (OK. Let�s finish HIP cookie with my R2) 652 I --> R (ESP protected data) 653 I <-- R (ESP protected data) 655 8.2. HIP KEYMAT 657 Moskowitz 12 659 Host Identity Payload February 2001 661 HIP keying material is derived from the Diffie-Hellman Kij produced 662 during the HIP exchange. The initiator has Kij during the creation 663 or the I2 packet, and the responder has Kij once it receives the I2 664 packet. This is why I2 can already contain encrypted information. 665 There are four keys that are derived from Kij; these are the 666 initiator and responder HIP keys and the initiator and responder ESP 667 keys. These four keys MUST be drawn sequentially (HIP initiator, 668 HIP responder, ESP initiator, EXP responder, and where the ESP 669 transform requires an encrypting and an authenticating key, they are 670 taken sequentially) from the Kij KEYMAT. For situations where the 671 amount of keying material desired is greater than that supplied by 672 Kij, KEYMAT is expanded by feeding Kij into the following operation: 674 KEYMAT = K1 | K2 | K3 | ... 675 where 677 K1 = SHA2-512(Kij | Resp-SPI) 678 K2 = SHA2-512(K1 | Resp-SPI) 679 K3 = SHA2-512(K2 | Resp-SPI) 680 etc. 682 In the situation where Kij is the result of a HIP rekey exchange, 683 there is only the need from one set of ESP keys. These are then the 684 only keys taken from Kij. 686 8.3. Refusing a HIP exchange 688 A HIP aware host may choose not to accept a HIP exchange 689 negotiation. If the host's policy is to only be an initiator, it 690 should begin its own HIP exchange. There is a risk of a race 691 condition if each host's policy is to only be an initiator, at which 692 point the HIP exchange will fail. 694 If the host's policy does not permit it to enter into a HIP exchange 695 with the initiator, it should send an ICMP Host Unreachable, 696 Administratively Prohibited message. A more complex HIP packet is 697 not used here as it actually opens up more potential DOS attacks 698 than a simple ICMP message. 700 8.4. Reboot restart of HIP 702 If a host reboots or times out, it has lost its HIP state. If it is 703 the initiator that loss state it simply restarts the HIP exchange. 704 The responder sends an R1 HIP packet, but does not reset its state 705 until it receives the I2 HIP packet. This is to handle DOS attacks 706 that simulate a reboot of the initiator. 708 If it is the responder that loss state, the recovery is more 709 involved. The initiator would send an ESP packet, the responder 710 will reply with an ICMP Host unreachable, Protocol unreachable. 711 After the initiator receives N such ICMP messages (default is 5; the 713 Moskowitz 13 715 Host Identity Payload February 2001 717 value of N is an initiator policy), the initiator resets its state 718 with the responder and restarts the HIP exchange. 720 Simulating a responder loss of state is a potential denial of 721 service attack. The initiator can manage this attack by dropping 722 any of the above ICMP messages if a responder ESP packet is received 723 within some reasonable delta after it sent its ESP packet. 725 8.5. Sequence Number State Machine 727 Ioo Initiator at no data packets sent, none received 728 Roo Responder at no data packets sent, none received 729 I1 or R1 Initial HIP packet from Host 730 I2 or R2 Second HIP with data packet from Host 731 IE or RE Data packet from Host with ESP 732 Inm or Rnm host sent packet n, and received packet m 734 +---------+ 735 | Ioo,Roo |<----------------------------+ 736 +---------+ | 737 | | 738 | I1->R | 739 | | 740 v | 741 +---------+ | 742 | Ioo,Roo | | 743 +---------+ | 744 | | 745 | R1->I | 746 | | 747 v | After I receives 748 +---------+ | x ICMPs 749 | Ioo,Roo | | 750 +---------+ | 751 | | 752 | I2->R | 753 | | 754 v | 755 +---------+ I2->R +---------+ | 756 | I1o,Ro1 |<-----------| Ioo,Rmn | | 757 +---------+ +---------+ | 758 | ^ | 759 | R2->I | R1->I | 760 | | | 761 v | | 762 +---------+ +---------+ | 763 | I11,R11 | | Ioo,Rmn | | 764 +---------+ +---------+ | +---------+ 765 | ^ | | Inm,Roo |-+ 766 | ESP | I1->R | +---------+ | 768 Moskowitz 14 770 Host Identity Payload February 2001 772 | Packets | | ^ | 773 v I reboots +---------+ | | Iesp->R | Ricmp 774 +---------+ ---------->| Ioo,Rmn | | | | ->I 775 +->| Inm,Rmn | or timeout +---------+ +---------+ | 776 | +---------+ -------------------------->| Inm,Roo |<---+ 777 | | | ^ R reboots +---------+ 778 |NES | | +------+ or timeout 779 |->R |Rrky|Irky | 780 | |->I |->R |NES 781 | | +----+ |->I 782 | v v | 783 +---------+ +---------+ 784 | In1,R1n | | I1m,Rm1 | {rekeying states} 785 +---------+ +---------+ 787 9. HIP Policies 789 There are a number of variables that will influence the HIP 790 exchanges that each host must support. All HIP implementations MUST 791 support at least 2 HIs, one to publish in DNS and one for anonymous 792 usage. Although anonymous HIs will be rarely used as responder HIs, 793 they will be common for initiators. Support for multiple HIs is 794 recommended. 796 Many initiators would want to use a different HI for different 797 responders. The implementations SHOULD provide for an ACL of 798 initiator HIT to responder HIT. This ACL SHOULD also include 799 preferred transform and local lifetimes. For HITs with HAAs, 800 wildcarding SHOULD be supported. Thus if a Community of Interest, 801 like Banking gets an RAA, a single ACL could be used. A global 802 wildcard would represent the general policy to be used. Policy 803 selection would be from most specific to most general. 805 The value of K used in the HIP R1 packet can also vary by policy. K 806 should never be greater than 8, but for trusted partners it could be 807 as low as 1. 809 Responders would need a similar ACL, representing which hosts they 810 accept HIP exchanges, and the preferred transform and local 811 lifetimes. Wildcarding SHOULD be support supported for this ACL 812 also. 814 10. Security Considerations 816 HIP is designed to provide secure authentication of hosts and 817 provide a fast key exchange for IPsec ESP. HIP also attempts to 818 limit the exposure of the host to various denial-of-service and man- 819 in-the-middle attacks. In so doing, HIP itself is subject to its 820 own DOS and MITM attacks that potentially could be more damaging to 821 a host's ability to conduct business as usual. 823 Moskowitz 15 825 Host Identity Payload February 2001 827 The Security Association for ESP is indexed by the LSI-SPI, not the 828 SPI and IP address. HIP enabled ESP is IP address independent. 829 This might seem to make it easier for an attacker, but ESP with 830 replay protection is already as well protected as possible, and the 831 removal of the IP address as a check should not increase the 832 exposure of ESP to DOS attacks. 834 Denial-of-service attacks take advantage of the cost of start of 835 state for a protocol on the responder compared to the 'cheapness' on 836 the initiator. HIP makes no attempt to increase the cost of the 837 start of state on the initiator, but makes an effort to reduce the 838 cost to the responder. This is done by having the responder start 839 the 3-way cookie exchange instead of the initiator, making the HIP 840 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 841 packet that the responder MAY use many times. The duration of use 842 is a paranoia versus throughput concern. Using the same Diffie- 843 Hellman values, I and Hash target has some risk. This risk needs to 844 be balanced against a potential storm of HIP I1 packets. 846 This shifting of the start of state cost to the initiator in 847 creating the I2 HIP packet, presents another DOS attack. The 848 attacker spoofs the I1 HIP packet and the responder sends out the R1 849 HIP packet. This could conceivably tie up the 'initiator' with 850 evaluating the R1 HIP packet, and creating the I2 HIP packet. The 851 defense against this attack is to simply ignore any R1 packet where 852 a corresponding I1 was not sent. 854 A second form of DOS attack is emulating the restart of state after 855 a reboot of one of the partners. To protect against such an attack 856 on the responder, it should send reply to an I1 HIP packet without 857 resetting its state. Only on receipt of an I2 HIP packet within a 858 reasonable delta after sending its R1 HIP packet, should the 859 responder reset its state. An initiator protects itself be ignoring 860 any R1 or R2 packets while it has state with R. 862 A third form of DOS attack is emulating the end of state. HIP has 863 no end of state packet. It relies on a local policy timer to end 864 state. 866 Man-in-the-middle attacks are difficult to defend against, without 867 third-party authentication. A skillful MITM could easily handle all 868 parts of HIP; but HIP indirectly provides the following protection 869 from a MITM attack. If the responder's HI is retrieved from a 870 signed DNS zone by the initiator, the initiator can use this to 871 validate the R1 HIP packet. 873 Likewise, if the initiator's HI is in a secure DNS zone, the 874 responder can retrieve it after it gets the I2 HIP packet and 875 validate that. However, since an initiator may choose to use an 876 anonymous HI, it knowingly risks a MITM attack. The responder may 877 choose not to accept a HIP exchange with an anonymous initiator. 879 Moskowitz 16 881 Host Identity Payload February 2001 883 Since not all hosts will ever support HIP, ICMP 'Destination 884 Protocol Unreachable' are to be expected and present a DOS attack. 885 Against an initiator, the attack would look like the responder does 886 not support HIP, but shortly after receiving the ICMP message, the 887 initiator would receive a valid R1 HIP packet. Thus to protect 888 against this attack, an initiator should not react to an ICMP 889 message until a reasonable delta time to get the real responder's R1 890 HIP packet. A similar attack against the responder is more 891 involved. First an ICMP message is expected if the I1 was a DOS 892 attack and the real owner of the spoofed IP address does not support 893 HIP. The responder SHOULD NOT act on this ICMP message to remove 894 the minimal state from the R1 HIP packet, but wait for either a 895 valid I2 HIP packet or the natural timeout of the R1 HIP packet. 896 This is to allow for a sophisticated attacker that is trying to 897 break up the HIP exchange. Likewise, the initiator should ignore 898 any ICMP message while waiting for an R2 HIP packet, deleting state 899 only after a natural timeout. 901 Another MITM attack is simulating a responder's rejection of a HIP 902 initiation. This is a simple ICMP Host Unreachable, 903 Administratively Prohibited message. A HIP packet was not used 904 because it would either have to have unique content, and thus 905 difficult to generate, resulting in yet another DOS attack, or just 906 as spoofable as the ICMP message. The defense against this MITM 907 attack is for the responder to wait a reasonable time period to get 908 a valid R1 HIP packet. If one does not come, then the Initiator has 909 to assume that the ICMP message is valid. Since this is the only 910 point in the HIP exchange where this ICMP message is appropriate, it 911 can be ignored at any other point in the exchange. 913 11. IANA Considerations 915 IANA has assigned Protocol number XX to HIP. 917 A new KEY RR protocol of XX is assigned to HIP and an algorithm of 918 XX is assigned to HIT128. 920 IANA will has also assigned new DNS OPT resource record OPTION-CODES 921 of Remotes_HIT [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and 922 Remotes_LSI [x]. 924 12. ICANN Considerations 926 ICANN are covered in the HIP Architecture [HIPARCH] document. 928 13. References 930 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", RFC 2119, March 1997. 933 Moskowitz 17 935 Host Identity Payload February 2001 937 [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", 938 draft-ietf-moskowitz-hip-arch-02.txt, January 2001. 940 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 941 draft-ietf-moskowitz-hip-impl-01.txt, January 2001. 943 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 944 Payload", RFC 2406, November 1998. 946 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 947 "Internet Security Association and Key Management Protocol", RFC 948 2408, November 1998. 950 [DNS], Mockapetris, P., "Domain Names - Implementation And 951 Specification", RFC 1035, November 1987. 953 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 954 RFC 2535, March 1999. 956 [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 957 1998. 959 [3DES], Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 960 Algorithms", RFC 2451, November 1998. 962 [HMACSHA1], Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within 963 ESP and AH", RFC 2404, November 1998. 965 14. Acknowledgments 967 The drive to create HIP came to being after attending the MALLOC 968 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave me 969 the assist to get HIP beyond 5 paragraphs of ideas. It has matured 970 considerably since the early drafts thanks to extensive input from 971 IETFers. Most importantly, its design goals are articulated and are 972 different from other efforts in this direction. Particular mention 973 goes to the members of the NameSpace Research Group of the IRTF. 974 Noel Chiappa provided the framework for LSIs and Kieth Moore the 975 impetuous to provide resolvability. Steve Deering provided 976 encouragement to keep working, as a solid proposal can act as a 977 proof of ideas for a research group. 979 Many others contributed; extensive security tips were provided by 980 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 981 Kocher taught me how to make the cookie exchange expensive for the 982 Initiator to respond, but easy for the Responder to validate. 983 Rodney Thayer and Hugh Daniels provide extensive feedback. John 984 Gilmore kept me challenged to provide something of value. I hope I 985 have. 987 15. Author's Address 989 Moskowitz 18 991 Host Identity Payload February 2001 993 Robert Moskowitz 994 ICSA Labs 995 1200 Walnut Bottom Rd. 996 Carlisle, PA 17013 997 Email: rgm@icsa.net 999 16. Copyright Statement 1001 Copyright (c) The Internet Society (2001). All Rights Reserved. 1002 This document and translations of it may be copied and furnished to 1003 others, and derivative works that comment on or otherwise explain it 1004 or assist in its implementation may be prepared, copied, published 1005 and distributed, in whole or in part, without restriction of any 1006 kind, provided that the above copyright notice and this paragraph 1007 are included on all such copies and derivative works. However, this 1008 document itself may not be modified in any way, such as by removing 1009 the copyright notice or references to the Internet Society or other 1010 Internet organizations, except as needed for the purpose of 1011 developing Internet standards in which case the procedures for 1012 copyrights defined in the Internet Standards process must be 1013 followed, or as required to translate it into languages other than 1014 English. 1016 The limited permissions granted above are perpetual and will not be 1017 revoked by the Internet Society or its successors or assigns. 1019 This document and the information contained herein is provided on an 1020 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1021 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1022 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1023 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1024 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Moskowitz 19