idnits 2.17.1 draft-moskowitz-hip-01.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 18 longer pages, the longest (page 1) being 61 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 646 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 (Feb 2000) is 8837 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 Internet Draft R. Moskowitz, ICSA.net 3 Document: Feb 2000 5 Host Identity Payload 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Table of Contents 30 1. Abstract...........................................................2 31 2. Conventions used in this document..................................2 32 3. Introduction.......................................................2 33 4. The Host Identity Payload..........................................3 34 4.1. HIP format.......................................................3 35 4.2. HIP Key Payload..................................................4 36 5. HIP Cookie Exchange................................................5 37 6. HIP Packets........................................................5 38 6.1. I1 - the HIP Initiator packet....................................5 39 6.2. R1 - the HIP Responder packet....................................5 40 6.3. I2 - the HIP Second Initiator packet.............................6 41 6.4. R2 - the HIP Second Responder packet.............................7 42 6.5. REK - the HIP Rekey Packet.......................................7 43 6.6. NES - the HIP New ESEL Packet....................................8 44 6.7. REA - the HIP Readdress Packet...................................9 45 6.8. HIP Fragmentation Support.......................................10 46 7. ESP with HIP......................................................10 47 7.1. Security Parameters Index (SPI).................................10 48 7.2. Supported Transforms............................................11 49 7.3. Sequence Number.................................................11 51 Moskowitz 1 52 Host Identity Payload February 2000 54 7.4. ESP usage with non-cryptographic HI.............................11 55 8. HIP Exchange packet flow..........................................11 56 8.1. The HIP Exchange................................................11 57 8.2. Refusing a HIP exchange.........................................12 58 8.3. Reboot restart of HIP...........................................12 59 8.4. Sequence Number State Machine...................................12 60 9. HIP Policies......................................................13 61 10. Security Considerations..........................................14 62 11. IANA Considerations..............................................16 63 12. ICANN Considerations.............................................16 64 13. References.......................................................16 65 14. Acknowledgments..................................................17 66 15. Author's Address.................................................17 67 16. Copyright Statement..............................................17 69 1. Abstract 71 This memo describes the Host Identity Payload (HIP) described in the 72 HIP architecture [HIPARCH] and the protocol that uses it to 73 establish a rapid authentication between two hosts. The various 74 forms of the Host Identity, HI, HIGH, and ESEL are covered in detail 75 and how they support the authentication and the establishment of 76 Keying Material that can be used by ESP [ESP]. 78 The basic state machine for HIP provides a HIP compliant host with 79 the resiliency to avoid many Dos attacks. The basic HIP exchange 80 for two public hosts shows the actual packet flow. Other HIP 81 exchanges, including those that work across NATs are covered in the 82 HIP implementation document [HIPIMPL]. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 88 this document are to be interpreted as described in [RFC-2119]. 90 3. Introduction 92 The Host Identity Payload (HIP) along with the HIP Protocol a rapid 93 exchange of Host Identities (HI) that also establishes a Security 94 Association for ESP. The HIP protocol is resistant to Denial-of- 95 Service (DOS) and Man-in-the-middle (MITM) attacks, and when used to 96 enable ESP, provides DOS and MITM protection to TCP and UDP. 98 The Host Identity Payload introduces a new namespace, the Host 99 Identity. There are three representations of the Host Identity, 100 the full Identity (HI), the Host Identity Global Hash (HIGH), and 101 the Endpoint Selector (ESEL). Three representations are used, as 102 each meets a different design goal of HIP, and none of them can be 103 removed and meet these goals. The HI is the Identity, normally a 105 Moskowitz 2 106 Host Identity Payload February 2000 108 public key. But since there are different public key algorithms 109 that can be used with different key lengths, the HI is not good for 110 using as the HIP packet identifier, or as a index into the various 111 operational tables needed to support HIP. 113 A hash of the HI, the Host Identity Global Hash (HIGH) thus becomes 114 the operational representation. It is 128 bits long, and the index 115 in the payload. However, in many environments, 128 bits is still 116 considered large. Also IPv4 is constrained with 32 bit API fields. 117 So the third representation, the ESEL is 32 bits. The ESEL provides 118 a compression of the HIGH with only a local scope so that it can be 119 carried efficiently in every packet (as the ESP SPI) and used in API 120 calls. 122 The HIP protocol is only four packets long. The four-packet design 123 helps make HIP DOS attack resilient. The protocol exchanges Diffie- 124 Hellman keys in the 2nd and 3rd packets and starts the cookie 125 exchange in the 2nd packet. The exchange uses the Diffie-Hellman 126 exchange to hide the Host Identities and exchanges these hidden 127 Identities in packets 3 and 4. Data datagrams start after the 4th 128 packet. 130 Finally, HIP is designed as an end-to-end authentication and key 131 establishment protocol. It lacks much of the fine-grain policy 132 control found in IKE that allows IKE to support complex gateway 133 policies. Thus HIP is not a complete replacement for IKE. In many 134 cases, particularly in spanning addressing realms, HIP would be the 135 preferred key establishment protocol. 137 4. The Host Identity Payload 139 The Host Identity Payload or HIP is IP protocol NN. HIP SHOULD be 140 carried in every datagram. However, since HIP datagrams are 141 relatively large (at least 20 bytes), and ESP already has all of the 142 functionality to maintain and protect state, the HIP payload is 143 'compressed' into an ESP payload after the HIP exchange. Thus in 144 practice, HIP packets only occur in datagrams to establish or change 145 HIP state. 147 4.1. HIP format 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Next Header | Payload Len | Type | RESERVED | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 | Host Identity Global Hash (HIGH) | 156 | | 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Moskowitz 3 161 Host Identity Payload February 2000 163 | | 164 | HIP Key payload (opt) | 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | ESP followed by IP payload (opt) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Next Header WILL be zero for those HIP packets that do not carry a 171 transport layer. Thus Next Header SHOULD only be zero or 50 (ESP). 173 Payload length is the length, in bytes, of the optional HIP Key 174 payload. It is zero if there is no payload. Thus the length of the 175 HIP envelope is 20 plus the payload length. 177 The Type indicates which HIP packet this is. 179 The HIGH is always 128 bits (16 bytes). 181 4.2. HIP Key Payload 183 The HIP Key Payload is used to carry the public key associated with 184 the HIGH and related security information. The format of the HIP 185 Key Payload is a simplification of a DNS message [DNS]. Since only 186 the answer portion of a message is needed, the payload consists of 187 the 16-bit unsigned ANCOUNT field in 'big-endian' ('network') byte 188 order of the message header followed by the indicated number of 189 resource records. 191 The resource records will either be a KEY (e.g. DSA and D-H), SIG 192 [DNSSEC], or OPT [EDNS] record. The owner name of the first 193 resource record in the HIP payload will be the host's FQDN if it has 194 one. If the host does not have (or does not wish to divulge) an 195 FQDN, the owner name will be the root domain (a single octet with a 196 numeric value of zero). All other resource records for the host 197 will use message compression (offset will always be 3). In all 198 resource records in the Key Payload, Class is always 1 and TTL is 199 always 0. The RDATA of the OPT record in the payload can contain 200 any of the following: 202 OPT Attribute Length Data 204 Remotes_HIGH 128 Remote's HIGH 205 HIP_COOKIE 192 3 64 bit fields: 206 Random # I, 207 K or random # J, 208 Hash target, Ltrunc(SHA1(I|J)) 209 or Utrunc(SHA1(I|J)) 210 HIP_TRANSFORM variable ISAKMP Transform [ISAKMP] 211 Without first 32 bits 212 Using Ipsec DOI 213 ESP_TRANSFORM variable ISAKMP Transform [ISAKMP] 214 Without first 32 bits 216 Moskowitz 4 217 Host Identity Payload February 2000 219 Using Ipsec DOI 220 Remotes_ESEL 32 Remote's ESEL 222 5. HIP Cookie Exchange 224 The HIP cookie exchange serves to manage the establishment of state 225 between the Initiator and Responder. This cookie exchange is 226 different than other 3-way exchanges in that the Responder starts 227 the exchange. Since the Responder starts the exchange, it can set 228 the difficulty for the Initiator. The Responder supplies a random 229 number I, and requires the Initiator hash it with a random number J. 230 The resulting hash's lowest order K bits MUST match a hash target 231 also supplied by the Responder. To accomplish this, the Initiator 232 will have to generate a number of Js until one produces the hash 233 target; the worst case SHOULD be 2^K hash operations. The Responder 234 needs only hash the Initiator's J with its I to prove that the 235 Initiator did its assigned task. 237 Thus the Responder can set the difficulty for Initiator, based on 238 its concern of trust of the Initiator. 240 6. HIP Packets 242 There are 7 HIP packets. Four are for the HIP exchange and the 243 other three are for mid-state changes (rekeying and address 244 migration). 246 6.1. I1 - the HIP Initiator packet 248 Next Header = 0 249 Type = 1 250 HIGH = Initiator's HIGH 251 Payload Contains: 252 Responder's HIGH in a KEY HIGH RR 254 The Initiator gets the responder's HIGH either from a DNS lookup of 255 the responder's FQDN or from a local table. 257 Since this packet is so easy to spoof even if it were signed, no 258 attempt is made to add to its generation or processing cost. 259 Implementation MUST be able to handle a storm of I1 packets, 260 discarding those with common content that arrive within a small time 261 delta. 263 6.2. R1 - the HIP Responder packet 265 Next Header = 0 266 Type = 2 267 HIGH = Responder's HIGH 269 Moskowitz 5 270 Host Identity Payload February 2000 272 Payload Contains: 273 Responder's HI in a KEY RR (e.g. KEY DSA RR) 274 Initiator's HIGH in a KEY HIGH RR 275 Responder's Diffie-Hellman public value in a KEY DH RR 276 HIP TRANSFORM in a OPT RR 277 ESP TRANSFORM in a OPT RR 278 HIP COOKIE in an OPT RR 279 HIP SIG in a SIG RR 281 If the responder has multiple HIs, the HIGH used MUST match 282 Initiator's request. 284 The Diffie-Hellman value is ephemeral, but can be reused over a 285 number of connections. In fact, as a defense against I1 storms, an 286 implementation MAY use the same Diffie-Hellman value for a period of 287 time, for example 15 minutes. By using a small number of Is for a 288 given Diffie-Hellman value, the R1 packets can be pre-computed and 289 delivered as quickly as I1 packets arrive. A scavenger process 290 should clean up unused DHs and Is. 292 The HIP_TRANSFORM contains the encryptions supported by the 293 responder to protect the HI exchange, in order of preference. 295 The ESP_TRANSFORM contains the ESP modes supported by the responder, 296 in order of preference. 298 HIP_COOKIE contains random I, K, and Hash Target. I is an internal 299 pointer to the HI, HIGH, and DH sent to the Initiator. It is only 300 used as a pointer until this cookie is used in an SA. K is number 301 of bits that the Initiator must match with the Hash Target. 303 The HIP SIG is calculated over whole HIP envelope. The Initiator 304 MUST validate this SIG. It MAY use either the HI in the packet or 305 the HI from a DNS query. 307 6.3. I2 - the HIP Second Initiator packet 309 Next Header = 0 310 Type = 3 311 HIGH = Initiator's HIGH 312 Payload Contains: 313 Responder's HIGH in a KEY HIGH RR 314 Responder's ESEL in an OPT RR 315 Initiator's Diffie-Hellman public value in a KEY DH RR 316 HIP TRANSFORM in a OPT RR 317 The following Resource Records are encrypted using the HIP 318 Transform and are in a HIP ENCRPYT OPT RR 319 HIP COOKIE in an OPT RR 320 ESP TRANSFORM in a OPT RR 321 Initiator's HI in a KEY RR (e.g. KEY DSA RR) 322 HIP SIG in a SIG RR 324 Moskowitz 6 325 Host Identity Payload February 2000 327 If the initiator has multiple HIs, the HI and HIGH used MUST match 328 Responder's reply. 330 The Diffie-Hellman value is ephemeral. A scavenger process should 331 clean up unused DHs and Js. 333 The HIP_TRANSFORM contains the encryptions to protect the HI 334 exchange selected by the initiator. 336 HIP_COOKIE contains random I and J, and Ltrunc(SHA1(I|J)) (that is 337 the low order bits of the SHA1 of I concatenated with J). The low 338 order K bits of Ltrunc(SHA1(I|J)) MUST match the low order K bits of 339 the Hash Target. J is an internal pointer to the HI, HIGH, and DH 340 sent to the Responder. 342 The ESP_TRANSFORM contains the ESP mode selected by the initiator. 344 The HIP SIG is calculated over whole HIP envelope. The Responder 345 MUST validate this SIG. It MAY use either the HI in the packet or 346 the HI from a DNS query. 348 6.4. R2 - the HIP Second Responder packet 350 Next Header = 0 351 Type = 4 352 HIGH = Responder's HIGH 353 Payload Contains: 354 Initiator's ESEL in an OPT RR 355 The following Resource Records are encrypted using the HIP 356 Transform and are in a HIP ENCRPYT OPT RR 357 Responder's HI in a KEY RR (e.g. KEY DSA RR) 358 HIP COOKIE in an OPT RR 359 HIP SIG in a SIG RR 361 HIP_COOKIE contains random I, Ltrunc(SHA1(I|J)), and 362 Rtrunc(SHA1(I|J)). 364 The HIP SIG is calculated over whole HIP envelope. The Initiator 365 MUST validate this SIG. 367 6.5. REK - the HIP Rekey Packet 369 During the life of a Security Association established by HIP, one of 370 the hosts may need to rekey. The reason for rekeying might be a 371 sequence number rap in ESP, or a local policy on use of a key. The 372 Rekey Payload permits a host to change its Diffie-Hellman key and 373 thus the keying material for ESP. The Rekey Packet is a HIP packet 374 with only a Diffie-Hellman RR in the HIP payload. The HIP packet is 375 transported within the ESP to provide authentication and replay 376 protection of the rekeying; there is no next protocol in the HIP 377 packet. Thus the datagram looks like: 379 Moskowitz 7 380 Host Identity Payload February 2000 382 IP[ESP[HIP(D-H)]] 384 The HIP content is: 386 Next Header = 0 387 Type = 5 388 HIGH = Sender's HIGH 389 Payload Contains: 390 New Diffie-Hellman public value in a KEY DH RR 392 When a host receives a Rekey Packet, its second from next ESP packet 393 MUST use the KEYMAT generated by the new Kij. The sending host MUST 394 expect at least a sequence number replay window worth of ESP packets 395 using the old Kij. Out of order delivery could result in needing 396 the old Kij after packets start arriving using the new Kij. Once 397 past the rekeying start, the sending host can drop the old Kij. 399 The first packet sent by the receiving system MUST be a HIP New ESEL 400 packet. This packet supplies the new ESEL for the rekeying system, 401 which cannot send any packets until it receives this packet. If it 402 does not receive a HIP New ESEL packet within a resonable round trip 403 delta, it MUST assume it or the HIP Rekey packet was lost and 404 renegotiate HIP as if in a reboot condition. 406 6.6. NES - the HIP New ESEL Packet 408 The HIP New ESEL Packet serves two functions. First it provides the 409 rekeying system with its new ESEL. Additionally, it provides any 410 intermediate system with the mapping of the old ESEL to the new. 411 This is important to systems like NATs [HIPIMPL] that use ESELs to 412 maintain address translation state. The new ESEL Packet is a HIP 413 packet with only a ESEL OPT RR in the HIP payload. The HIP packet 414 is transported within the ESP to provide authentication and replay 415 protection. There MAY be a next protocol of HIP if the receiving 416 host chooses to rekey at this time. Thus the datagram looks like: 418 IP[ESP[HIP(ESEL)]] 419 or 420 IP[ESP[HIP(ESEL)[HIP(D-H)]]] 422 The HIP content is: 424 Next Header = 0 or NN (HIP's protocol number) 425 Type = 6 426 HIGH = Sender's HIGH 427 Payload Contains: 428 Rekeyer's new ESEL in an OPT RR 429 HIP SIG in a SIG RR 431 Since intermediate systems need this new ESEL, this ESP packet MUST 432 NOT be encrypted, that is ESP NULL is used. The rekeying system 434 Moskowitz 8 435 Host Identity Payload February 2000 437 MUST anticipate this potential deviation from the agreed ESP 438 Transform. It will recognize the packet as one arriving after it 439 sent the HIP Rekey packet and the ESP Next Header will by NN BEFORE 440 it decrypts, and the beginning of the ESP content is recognized as a 441 HIP packet. 443 Intermediate systems that use the ESEL will have to inspect ALL ESP 444 packets for a HIP New ESEL packet. This is a potential Dos attack 445 against the Intermediate system, as it cannot perform the ESP 446 authentication. Thus the HIP record is signed with the HIP SIG RR 447 for the benefit of the Intermediate systems. A further step against 448 attack for the Intermediate systems is to implement ESP's replay 449 protection of windowing the sequence number. 451 Since this packet CANNOT be encrypted, the sending system MAY choose 452 to send its Rekey packet (if it is rekeying immediately by local 453 policy) in a separate packet using the new ESEL and Kij. 455 6.7. REA - the HIP Readdress Packet 457 During the life of a Security Association established by HIP, one of 458 the hosts may change its IP address. The reason for readdressing 459 might be a PPP reconnect, DHCP new lease, or IPv6 address prefix 460 change. The readdressing event might be from mobility or Internet 461 reconnection. Although HIP enables ESP to be independent of the 462 internetworking layer, there still needs to be a mapping of ESEL and 463 HIGH to an IP address. 465 The Readdress Packet permits a host to notify its partners of an 466 address change. The Readdress Packet is a HIP packet with an A or 467 A6 RR in the HIP payload. The HIP packet is transported within the 468 ESP to provide authentication and replay protection; there is no 469 next protocol in the HIP packet. Thus the datagram looks like: 471 IP[ESP[HIP(A|A6)]] 473 The HIP content is: 475 Next Header = 0 476 Type = 7 477 HIGH = Sender's HIGH 478 Payload Contains: 479 New address in an A or A6 RR 480 HIP SIG in a SIG RR 482 Since intermediate systems need this new address, this ESP packet 483 MUST NOT be encrypted, that is ESP NULL is used. The receiving 484 system MUST anticipate this potential deviation from the agreed ESP 485 Transform. It will recognize the packet as one with the ESP Next 486 Header of NN BEFORE it decrypts, and the beginning of the ESP 487 content is recognized as a HIP packet. 489 Moskowitz 9 490 Host Identity Payload February 2000 492 Intermediate systems that use the address will have to inspect ALL 493 ESP packets for a HIP Readdress packet. This is a potential Dos 494 attack against the Intermediate system, as it cannot perform the ESP 495 authentication. Thus the HIP record is signed with the HIP SIG RR 496 for the benefit of the Intermediate systems. A further step against 497 attack for the Intermediate systems is to implement ESP's replay 498 protection of windowing the sequence number. 500 6.8. HIP Fragmentation Support 502 A HIP implementation MUST support IP fragmentation/reassembly. HIP 503 packets can get large, and may encounter low MTUs along their routed 504 path. Since HIP does not provide a mechanism to use multiple IP 505 datagrams for a single HIP packet, support of path MTU discovery 506 does not bring any value to HIP. HIP aware NAT systems MUST perform 507 any IP reassembly/fragmentation. 509 7. ESP with HIP 511 HIP sets up a Security Association (SA) to enable ESP in an end-to- 512 end manner that can span addressing realms (i.e. across NATs). This 513 is accomplished through the various information that is exchanged 514 within HIP. It is anticipated that since HIP is designed for host 515 usage, that is not for gateways, that only ESP transport mode will 516 be supported with HIP. The SA is not bound to an IP address, all 517 internal control of the SA is by the HIGH and ESEL. Thus a host can 518 easily change its address using Mobile IP, DHCP, PPP, or IPv6 519 readdressing and still maintain the SA. And since the transports 520 are bound to the SA (ESEL), any active transport is also maintained. 521 So real-world conditions like loss of a PPP connection and its 522 reestablishment or a mobile cell change will not require a HIP 523 negotiation or disruption of transport services. 525 Since HIP does not negotiate any lifetimes, all lifetimes are local 526 policy. The only lifetimes a HIP implementation MUST support are 527 sequence number rollover (for replay protection), and SA timeout. 528 An SA times out if no packets are received using that SA. The 529 default timeout value is 15 minutes. Implementations MAY support 530 lifetimes for the various ESP transforms. Note that HIP does not 531 offer any service comparable with IKE's Quick Mode. A Diffie- 532 Hellman calculation is needed for each rekeying. 534 7.1. Security Parameters Index (SPI) 536 HIP uses the ESELs as the SPIs in ESP. This provides simple 537 compression of the HIP data from all packets after the HIP exchange. 538 This does result in a per host-pair SPI, and a decrease of policy 539 granularity over other KMPs like IKE. 541 Moskowitz 10 542 Host Identity Payload February 2000 544 When a host rekeys, it gets a new ESEL and thus SPI from its 545 partner. 547 7.2. Supported Transforms 549 All HIP implementations MUST support 3DES [3DES] and HMAC-SHA-1-96 550 [HMACSHA1]. If the Initiator does not support any of the transforms 551 offered by the Responder in the R1 HIP packet, it MUST use 3DES and 552 HMAC-SHA-1-96 and state so in the I2 HIP packet. 554 7.3. Sequence Number 556 The Sequence Number field is MANDATORY in ESP. Anti-replay 557 protection MUST be used in an ESP SA established with HIP. 559 This means that each host MUST rekey before its sequence number 560 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 561 one Diffie-Hellman key is changed, that of the rekeying host. Thus 562 if one host rekeys, the other host SHOULD rekey as well. 564 7.4. ESP usage with non-cryptographic HI 566 Even if the Host Identity is not cryptographically based, ESP MUST 567 still be used after the HIP exchange between the two hosts. The HIP 568 TRANSFORM in this case will be left out of the HIP exchange, and the 569 ESP envelope will not have any authentication of encryption. The 570 purpose of using ESP in this situation is to have the SPI (ESEL) for 571 associating the packets with the HIGHs, and the sequence # for 572 replay protection. 574 8. HIP Exchange packet flow 576 A HIP exchange SHOULD be initiated whenever the DNS lookup returns 577 HIP KEY resource records. Since some hosts may choose not to have 578 information in DNS, hosts SHOULD support opportunistic HIP 579 [HIPIMPL]. 581 Only Initiator and Responder in common addressing realm (i.e. both 582 public or both private) is shown here. Other packet flow scenarios 583 are covered in the HIP implementation documents. 585 8.1. The HIP Exchange 587 Initiator gets IP address, HI, and HIGH of Responder somehow. 588 Hard coded (bad) 589 DNS lookup 590 DNSSEC important 592 I --> DNS (lookup R) 594 Moskowitz 11 595 Host Identity Payload February 2000 597 I <-- DNS (R's address, HI, and HIGH) 598 I1 I --> R (Hi. Here is my I1, let's talk HIP) 599 R1 I <-- R (OK. Here is my R1, handle this HIP cookie) 600 I2 I --> R (Compute, compute, here is my counter I2) 601 R2 I <-- R (OK. Let�s finish HIP cookie with my R2) 602 I --> R (ESP protected data) 603 I <-- R (ESP protected data) 605 8.2. Refusing a HIP exchange 607 A HIP aware host may choose not to accept a HIP exchange 608 negotiation. If the host's policy is to only be an initiator, it 609 should begin its own HIP exchange. There is a risk of a race 610 condition if each host's policy is to only be an initiator, at which 611 point the HIP exchange will fail. 613 If the host's policy does not permit it to enter into a HIP exchange 614 with the initiator, it should send an ICMP Host Unreachable, 615 Administratively Prohibited message. A more complex HIP packet is 616 not used here as it actually opens up more potential DOS attacks 617 than a simple ICMP message. 619 8.3. Reboot restart of HIP 621 If a host reboots or times out, it has lost its HIP state. If it is 622 the initiator that loss state it simply restarts the HIP exchange. 623 The responder sends an R1 HIP packet, but does not reset its state 624 until it receives the I2 HIP packet. This is to handle DOS attacks 625 that simulate a reboot of the initiator. 627 If it is the responder that loss state, the recovery is more 628 involved. The initiator would send an ESP packet, the responder 629 will reply with an ICMP Host unreachable, Protocol unreachable. 630 After the initiator receives N such ICMP messages (default is 5; the 631 value of N is an initiator policy), the initiator resets its state 632 with the responder and restarts the HIP exchange. 634 Simulating a responder loss of state is a potential denial of 635 service attack. The initiator can manage this attack by dropping 636 any of the above ICMP messages if a responder ESP packet is received 637 within some reasonable delta after it sent its ESP packet. 639 8.4. Sequence Number State Machine 641 Ioo Initiator at no data packets sent, none received 642 Roo Responder at no data packets sent, none received 643 I1 or R1 Initial HIP packet from Host 644 I2 or R2 Second HIP with data packet from Host 645 IE or RE Data packet from Host with ESP 646 Inm or Rnm host sent packet n, and received packet m 648 Moskowitz 12 649 Host Identity Payload February 2000 651 +---------+ 652 | Ioo,Roo |<----------------------------+ 653 +---------+ | 654 | | 655 | I1->R | 656 | | 657 v | 658 +---------+ | 659 | Ioo,Roo | | 660 +---------+ | 661 | | 662 | R1->I | 663 | | 664 v | After I receives 665 +---------+ | x ICMPs 666 | Ioo,Roo | | 667 +---------+ | 668 | | 669 | I2->R | 670 | | 671 v | 672 +---------+ I2->R +---------+ | 673 | I1o,Ro1 |<-----------| Ioo,Rmn | | 674 +---------+ +---------+ | 675 | ^ | 676 | R2->I | R1->I | 677 | | | 678 v | | 679 +---------+ +---------+ | 680 | I11,R11 | | Ioo,Rmn | | 681 +---------+ +---------+ | +---------+ 682 | ^ | | Inm,Roo |-+ 683 | ESP | I1->R | +---------+ | 684 | Packets | | ^ | 685 v I reboots +---------+ | | Iesp->R | Ricmp 686 +---------+ ---------->| Ioo,Rmn | | | | ->I 687 +->| Inm,Rmn | or timeout +---------+ +---------+ | 688 | +---------+ -------------------------->| Inm,Roo |<---+ 689 | | | ^ R reboots +---------+ 690 |NES | | +------+ or timeout 691 |->R |Rrky|Irky | 692 | |->I |->R |NES 693 | | +----+ |->I 694 | v v | 695 +---------+ +---------+ 696 | In1,R1n | | I1m,Rm1 | {rekeying states} 697 +---------+ +---------+ 699 9. HIP Policies 701 Moskowitz 13 702 Host Identity Payload February 2000 704 There are a number of variables that will influence the HIP 705 exchanges that each host must support. All HIP implementations MUST 706 support at least 2 HIs, one to publish in DNS and one for anonymous 707 usage. Although anonymous HIs will be rarely used as responder HIs, 708 they will be common for initiators. Support for multiple HIs is 709 recommended. 711 Many initiators would want to use a different HI for different 712 responders. The implementations SHOULD provide for an ACL of 713 initiator HIGH to responder HIGH. This ACL SHOULD also include 714 preferred transform and local lifetimes. For HIGHs with HAAs, 715 wildcarding SHOULD be supported. Thus if a Community of Interest, 716 like Banking gets an RAA, a single ACL could be used. A global 717 wildcard would represent the general policy to be used. Policy 718 selection would be from most specific to most general. 720 The value of K used in the HIP R1 packet can also vary by policy. K 721 should never be greater than 8, but for trusted partners it could be 722 as low as 1. 724 Responders would need a similar ACL, representing which hosts they 725 accept HIP exchanges, and the preferred transform and local 726 lifetimes. Wildcarding SHOULD be support supported for this ACL 727 also. 729 10. Security Considerations 731 HIP is designed to provide secure authentication of hosts and 732 provide a fast key exchange for IPsec ESP. HIP also attempts to 733 limit the exposure of the host to various denial-of-service and man- 734 in-the-middle attacks. In so doing, HIP itself is subject to its 735 own DOS and MITM attacks that potentially could be more damaging to 736 a host's ability to conduct business as usual. 738 The Security Association for ESP is indexed by the ESEL-SPI, not the 739 SPI and IP address. HIP enabled ESP is IP address independent. 740 This might seem to make it easier for an attacker, but ESP with 741 replay protection is already as well protected as possible, and the 742 removal of the IP address as a check should not increase the 743 exposure of ESP to DOS attacks. 745 Denial-of-service attacks take advantage of the cost of start of 746 state for a protocol on the responder compared to the 'cheapness' on 747 the initiator. HIP makes no attempt to increase the cost of the 748 start of state on the initiator, but makes an effort to reduce the 749 cost to the responder. This is done by having the responder start 750 the 3-way cookie exchange instead of the initiator, making the HIP 751 protocol 4 packets long. In doing this, packet 2 becomes a 'stock' 752 packet that the responder MAY use many times. The duration of use 753 is a paranoia versus throughput concern. Using the same Diffie- 754 Hellman values, I and Hash target has some risk. This risk needs to 755 be balanced against a potential storm of HIP I1 packets. 757 Moskowitz 14 758 Host Identity Payload February 2000 760 This shifting of the start of state cost to the initiator in 761 creating the I2 HIP packet, presents another DOS attack. The 762 attacker spoofs the I1 HIP packet and the responder sends out the R1 763 HIP packet. This could conceivably tie up the 'initiator' with 764 evaluating the R1 HIP packet, and creating the I2 HIP packet. The 765 defense against this attack is to simply ignore any R1 packet where 766 a corresponding I1 was not sent. 768 A second form of DOS attack is emulating the restart of state after 769 a reboot of one of the partners. To protect against such an attack 770 on the responder, it should send reply to an I1 HIP packet without 771 resetting its state. Only on receipt of an I2 HIP packet within a 772 reasonable delta after sending its R1 HIP packet, should the 773 responder reset its state. An initiator protects itself be ignoring 774 any R1 or R2 packets while it has state with R. 776 A third form of DOS attack is emulating the end of state. HIP has 777 no end of state packet. It relies on a local policy timer to end 778 state. 780 Man-in-the-middle attacks are difficult to defend against, without 781 third-party authentication. A skillful MITM could easily handle all 782 parts of HIP; but HIP indirectly provides the following protection 783 from a MITM attack. If the responder's HI is retrieved from a 784 signed DNS zone by the initiator, the initiator can use this to 785 validate the R1 HIP packet. 787 Likewise, if the initiator's HI is in a secure DNS zone, the 788 responder can retrieve it after it gets the I2 HIP packet and 789 validate that. However, since an initiator may choose to use an 790 anonymous HI, it knowingly risks a MITM attack. The responder may 791 choose not to accept a HIP exchange with an anonymous initiator. 793 Since not all hosts will ever support HIP, ICMP 'Destination 794 Protocol Unreachable' are to be expected and present a DOS attack. 795 Against an initiator, the attack would look like the responder does 796 not support HIP, but shortly after receiving the ICMP message, the 797 initiator would receive a valid R1 HIP packet. Thus to protect 798 against this attack, an initiator should not react to an ICMP 799 message until a reasonable delta time to get the real responder's R1 800 HIP packet. A similar attack against the responder is more 801 involved. First an ICMP message is expected if the I1 was a DOS 802 attack and the real owner of the spoofed IP address does not support 803 HIP. The responder SHOULD NOT act on this ICMP message to remove 804 the minimal state from the R1 HIP packet, but wait for either a 805 valid I2 HIP packet or the natural timeout of the R1 HIP packet. 806 This is to allow for a sophisticated attacker that is trying to 807 break up the HIP exchange. Likewise, the initiator should ignore 808 any ICMP message while waiting for an R2 HIP packet, deleting state 809 only after a natural timeout. 811 Moskowitz 15 812 Host Identity Payload February 2000 814 Another MITM attack is simulating a responder's rejection of a HIP 815 initiation. This is a simple ICMP Host Unreachable, 816 Administratively Prohibited message. A HIP packet was not used 817 because it would either have to have unique content, and thus 818 difficult to generate, resulting in yet another DOS attack, or just 819 as spoofable as the ICMP message. The defense against this MITM 820 attack is for the responder to wait a reasonable time period to get 821 a valid R1 HIP packet. If one does not come, then the Initiator has 822 to assume that the ICMP message is valid. Since this is the only 823 point in the HIP exchange where this ICMP message is appropriate, it 824 can be ignored at any other point in the exchange. 826 11. IANA Considerations 828 IANA has assigned Protocol number XX to HIP. 830 A new KEY RR protocol of XX is assigned to HIP and an algorithm of 831 XX is assigned to HIGH128. 833 IANA will has also assigned new DNS OPT resource record OPTION-CODES 834 of Remotes_HIGH [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and 835 Remotes_ESEL [x]. 837 12. ICANN Considerations 839 ICANN are covered in the HIP Architecture [HIPARCH] document. 841 13. References 843 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", RFC 2119, March 1997. 846 [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", 847 draft-ietf-moskowitz-hip-arch-01.txt, February 2000. 849 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 850 draft-ietf-moskowitz-hip-impl-00.txt, February 2000. 852 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 853 Payload", RFC 2406, November 1998. 855 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 856 "Internet Security Association and Key Management Protocol", RFC 857 2408, November 1998. 859 [DNS], Mockapetris, P., "Domain Names - Implementation And 860 Specification", RFC 1035, November 1987. 862 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 863 RFC 2535, March 1999. 865 Moskowitz 16 866 Host Identity Payload February 2000 868 [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 869 1998. 871 [3DES], Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 872 Algorithms", RFC 2451, November 1998. 874 [HMACSHA1], Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within 875 ESP and AH", RFC 2404, November 1998. 877 14. Acknowledgments 879 The drive to create HIP came to being after attending the MALLOC 880 meeting at IETF 43. Baiju Patel and Hilarie Orman really gave me 881 the assist to get HIP beyond 5 paragraphs of ideas. It has matured 882 considerably since the early drafts thanks to extensive input from 883 IETFers. Most importantly, its design goals are articulated and are 884 different from other efforts in this direction. Particular mention 885 goes to the members of the NameSpace Research Group of the IRTF. 886 Noel Chiappa provided the framework for ESELs and Kieth Moore the 887 impetuous to provide resolvability. Steve Deering provided 888 encouragement to keep working, as a solid proposal can act as a 889 proof of ideas for a research group. 891 Many others contributed; extensive security tips were provided by 892 Steve Bellovin. Rob Austein kept the DNS parts on track. Paul 893 Kocher taught me how to make the cookie exchange expensive for the 894 Initiator to respond, but easy for the Responder to validate. 895 Rodney Thayer and Hugh Daniels provide extensive feedback. John 896 Gilmore kept me challenged to provide something of value. I hope I 897 have. 899 15. Author's Address 901 Robert Moskowitz 902 ICSA.net 903 1200 Walnut Bottom Rd. 904 Carlisle, PA 17013 905 Email: rgm@icsa.net 907 16. Copyright Statement 909 Copyright (c) The Internet Society (2000). All Rights Reserved. 910 This document and translations of it may be copied and furnished to 911 others, and derivative works that comment on or otherwise explain it 912 or assist in its implementation may be prepared, copied, published 913 and distributed, in whole or in part, without restriction of any 914 kind, provided that the above copyright notice and this paragraph 915 are included on all such copies and derivative works. However, this 916 document itself may not be modified in any way, such as by removing 918 Moskowitz 17 919 Host Identity Payload February 2000 921 the copyright notice or references to the Internet Society or other 922 Internet organizations, except as needed for the purpose of 923 developing Internet standards in which case the procedures for 924 copyrights defined in the Internet Standards process must be 925 followed, or as required to translate it into languages other than 926 English. 928 The limited permissions granted above are perpetual and will not be 929 revoked by the Internet Society or its successors or assigns. 931 This document and the information contained herein is provided on an 932 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 933 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 934 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 935 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 936 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 938 Moskowitz 18