idnits 2.17.1 draft-moskowitz-hip-arch-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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 65 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. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 8809 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) == Unused Reference: 'ESP' is defined on line 633, but no explicit reference was found in the text -- No information found for draft-ietf-moskowitz-hip - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIP' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' ** Obsolete normative reference: RFC 2673 (ref. 'DNSBIN') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- No information found for draft-ietf-moskowitz-hip-impl - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIPIMPL' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 R. Moskowitz, ICSA.net 4 Internet Draft 6 Document: Feb 2000 8 Host Identity Payload 10 Architecture 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Table of Contents 35 1. Abstract...........................................................2 36 2. Conventions used in this document..................................2 37 3. Introduction.......................................................2 38 4. Background.........................................................3 39 5. The Host Identity..................................................4 40 5.1. Host Identity....................................................5 41 5.2. Host Identity Global Hash (HIGH).................................5 42 5.2.1. Storing HIGH in DNS............................................6 43 5.3. Host Assigning Authority (HAA) field.............................6 44 5.4. Endpoint Selector (ESEL).........................................7 45 6. Using the Host Identity............................................7 46 7. Mobility via HIP...................................................8 47 8. HIP and NATs.......................................................9 48 8.1. HIP and TCP Checksum.............................................9 49 9. HIP Policies.......................................................9 50 10. Security Considerations..........................................10 51 10.1. HIGHs used in ACLs.............................................11 52 10.2. Non-security Considerations....................................12 53 11. IANA Considerations..............................................12 55 Moskowitz 1 56 Host Identity Payload Architecture February 2000 58 12. ICANN Considerations.............................................12 59 13. References.......................................................12 60 14. Acknowledgments..................................................13 61 15. Author's Address.................................................13 62 16. Copyright Statement..............................................13 64 1. Abstract 66 This memo describes the reasoning behind proposing a new namespace, 67 the Host Identity, and a payload, between the Internetworking and 68 Transport layers, to carry this identity. Herein is presented the 69 basics of the current namespaces, strengths and weaknesses, and how 70 a new namespace will add completeness to them. This new namespace's 71 roles in the protocols are defined. 73 2. Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in [RFC-2119]. 79 3. Introduction 81 The Internet has created two namespaces: Internet Protocol (IP) 82 addresses, and Domain Name Services (DNS) names. These two 83 namespaces have a set of features and abstractions that have powered 84 the Internet to what it is today. They also have a number of 85 weaknesses. IP addresses define an interface, not a host and not 86 every host has one permanently, so they cannot reliably be used for 87 host authentication systems. Further, IP addresses are bound to the 88 transport within the hosts (e.g. in the Transport Control Block, 89 TCB) so that a change to an IP address will disrupt any existing 90 transport flow. 92 Few systems on the Internet have DNS names. DNS names are also only 93 indirect references to IP addresses, though this changes in part 94 with DNSSEC and KEY records. Although each namespace can be 95 stretched (IP with v6, DNS with KEY records), neither can adequately 96 provide for host authentication or act as a separation between 97 Internetworking and Transport layers. 99 The Host Identity (HI) namespace is assigned to each host, or 100 technically its networking kernel. Each host will have at least one 101 HI, which can either be public (published in DNS), or anonymous. 102 Client systems will tend to have both public and anonymous HIs. 104 Although the HI can be used in many authentication systems, its 105 principle design calls out for a new protocol header and exchange 106 [HIP] that will support trust between systems, enhance mobility and 107 dynamic IP renumbering, and greatly reduce Denial Of Service (DOS) 108 attacks. 110 Moskowitz 2 111 Host Identity Payload Architecture February 2000 113 4. Background 115 The Internet is built from three principle components: Computing 116 platforms, Packet transport infrastructure, and Services 117 (applications). The Internet exists to service two principle 118 components: People and Robotic processes (silicon based people, if 119 you will). All these components need to be named in order to 120 interact in a scalable manner. 122 There are three principle namespaces in use in the Internet for 123 these components: IP numbers, Domain Names, and Email addresses. 124 Where Email addresses are really only an extension of Domain Names. 126 IP addresses provide naming for the Transport Infrastructure 127 interfaces on computing platforms. More than just naming the 128 interface, IP addresses are used directly in the TCB in all TCP 129 implementations. IP addresses assignments are centrally controlled 130 and delegated in blocks. There is little anonymity in IP addresses. 131 IPv4 addresses provide a unique (non-singular sometimes), but non- 132 global names. IPv6 addresses MAY provide globally unique (non- 133 singular regularly?) names. Most IP address assignment is 134 transient; making IP addresses an unreliable namespace outside of 135 packet delivery. 137 Domain Names provide hierarchically assigned names for some 138 computing platforms and some services. Each hierarchy is delegated 139 from the level above; there is no anonymity in Domain Names. 141 Email addresses provide naming for both carbon and silicon based 142 people. Email addresses are extensions of Domain Names, only in so 143 far as a named service is responsible for managing a person's mail. 144 There is some anonymity in Email addresses. 146 There are four critical deficiencies with the current namespaces. 147 Computing platforms are not well named with the current namespaces. 148 Dynamic readdressing cannot be directly managed. Anonymity is not 149 provided in a consistent, trustable manner. And authentication for 150 systems and datagrams is not provided. 152 A namespace for computing platforms can be used in end-to-end 153 operations independent of the evolution of the internetworking 154 layer and across the many transport layers. This could support 155 rapid readdressing of the internetworking layer either from 156 mobility or renumbering. 158 If this namespace is cryptographically based, it can also 159 provide authentication services for IPsec. If this namespace 160 is locally created without requiring registration, it can 161 provide anonymity. 163 Moskowitz 3 164 Host Identity Payload Architecture February 2000 166 Such a namespace (for computing platforms) should have the following 167 characteristics: 169 It is applied to the IP 'kernel'. The IP kernel is the 170 'component' between services and the packet transport 171 infrastructure. 173 It should fully decouple the Internetworking layer from the 174 higher layers. It should replace all occurrences of IP 175 addresses within applications (like in the TCB). This may 176 require API changes. 178 It should not mandate any infrastructure. Deployment must come 179 from the bottom up, in a pairwise deployment. 181 It should be fixed length, for easy inclusion in datagrams and 182 programming interfaces (e.g the TCB). 184 It should be affordable when used in protocols. This is 185 primarily a packet size issue. 187 It MUST be statistically globally unique. 64 bits is 188 inadequate (1% chance of collision in a population of 640M); 189 thus approximately 128 bits should be used. 191 It should have a localized abstraction so that it can be used 192 in existing protocols and APIs. 194 It SHOULD be locally created. This can provide anonymity at 195 the cost of making resolvability very difficult. 197 Sometimes it MAY contain a delegation component. This 198 is the cost of resolvability. 200 It SHOULD provide authentication services. This is a preferred 201 function. 203 It should be long lived, but replaceable at any time. This 204 impacts access control lists; short lifetimes will tend to 205 result in tedious list maintenance or require a namespace 206 infrastructure for central control of access lists. 208 This new namespace will be called the Host Identity. It will 209 require its own protocol layer (the Host Identity Payload), between 210 the Internetworking and Transport layers. It will be based on 211 Public Key Cryptography to supply authentication services. Properly 212 designed, it can deliver all of the above stated requirements. 214 5. The Host Identity 216 The Host Identity represents a statistically globally unique name 217 for naming any system with an IP stack. This identity is normally 219 Moskowitz 4 220 Host Identity Payload Architecture February 2000 222 associated with an IP stack. A system can have multiple identities, 223 some 'well known', some anonymous. A system may self assert its 224 identity, or may use a third-party authenticator like DNSSEC, PGP, 225 or X.509 to 'notarize' the identity assertion. DNSSEC is the MUST 226 implement authenticator for the Host Identity. 228 Although the Host Identity can be any name that can claim 229 'statistically globally unique', a public key of a 'public key' pair 230 makes the best Host Identity. As documented in the Host Identity 231 Payload (HIP) protocol [HIP], a public key based HI can authenticate 232 the HIP packets and protect them for man-in-the-middle attacks. And 233 since authenticated datagrams are MANDITORY to provide much of HIP's 234 Dos protection, the Diffie-Hellman exchange in HIP has to be 235 authenticated. Thus only public key HI and authenticated datagrams 236 SHOULD be supported. The non-cryptographic forms of HI and HIP are 237 presented to complete the theory of HI, but SHOULD NOT be 238 implemented as they could produce worst DOS attacks than the 239 internet has without HI. 241 5.1. Host Identity 243 Host Identity adds two main features to Internet protocols. The 244 first is a decoupling of the internetworking and transport layers. 245 This decoupling will allow for independent evolution of the two 246 layers. Additionally it can provide end-to-end services over 247 multiple internetworking realms. The second feature is host 248 authentication. If the Host Identity is a public key, this key can 249 be used to authenticate security protocols like IPsec. 251 The preferred structure of the Host Identity is that of a public key 252 pair. DSA is the MUST implement algorithm for any implementation 253 supporting public keys for the Host Identity. Any other Internet 254 naming convention MAY be used for the Host Identity. However, these 255 should only be used in situations of high trust - low risk. That is 256 any place where host authentication is not needed (no risk of host 257 spoofing) and no use of IPsec. 259 The Host Identity is never directly used in any Internet protocol. 260 It may be stored in various DNS or LDAP directories as identified in 261 the HIP architecture and it is passed in the HIP payload. If the 262 Host Identity is a public key, it SHOULD be stored in a DNS KEY RR 263 with the protocol set to HIP. A Host Identity Global Hash (HIGH) is 264 used in protocols to represent the Host Identity. Another 265 representation of the Host Identity, the Endpoint Selector (ESEL) 266 can also be used in protocols and APIs. ESEL's advantage over HIGH 267 is its size; its disadvantage is its local scope. 269 5.2. Host Identity Global Hash (HIGH) 271 The Host Identity Global Hash is a 128 bit field. There are two 272 advantages of using a hash over the actual Identity in protocols. 274 Moskowitz 5 275 Host Identity Payload Architecture February 2000 277 First its fix length makes for easier protocol coding and also 278 better manages the packet size cost of this technology. Secondly, 279 it presents a consistent format to the protocol whatever underlying 280 Identity technology is used. 282 When the Host Identity is a public key, HIGH functions much like the 283 SPI does in IPsec. However, instead of being an arbitrary 32-bit 284 value that, in combination with the destination IP address and 285 security protocol (ESP), uniquely identifies the Security 286 Association for a datagram, HIGH identifies the public key that can 287 validate the packet authentication. HIGH SHOULD be unique in the 288 whole IP universe. If there is more than one public key for a HIGH, 289 the HIGH acts as a hint for the correct public key to use. 291 There are two formats for HIGH. Bit 0 is used to differentiate the 292 formats. If Bit 0 is zero, then the rest of HIGH is a 127 bits of a 293 Hash of the key. For example, if the Identity is DSA, these bits 294 are the least significant 127 bits of the SHA-1 [FIPS-180-1] hash of 295 the DSA public key Host Identity. 297 If Bit 0 is one, then the next 63 bits is the Host Assigning 298 Authority field, and only the last 64 bits come from a hash of the 299 Host Identity. This format for HIGH is recommended for 'well known' 300 systems. It is possible to support a resolution mechanism for these 301 names in directories like DNS. 303 The birthday paradox sets a bound for the expectation of collisions. 304 It is based on the square root of the number of values. A 64-bit 305 hash, then, would put the chances of a collision at 50-50 with 2^32 306 hosts (4 billion). A 1% chance of collision would occur in a 307 population of 640M and a .001% collision chance in a 20M population. 308 A 128 bit hash will have the same .001% collision chance in a 309 9x10^16 population. 311 5.2.1. Storing HIGH in DNS 313 The HIGH SHOULD be stored in DNS. The exception to this is 314 anonymous identities. The HIGH is stored in a new KEY RR. The HIGH 315 KEY RR will have all flags set to ZERO, its protocol set to HIP, and 316 algorithm set to HIGH128. The 'public key' field of the HIGH KEY RR 317 will be the 128 bit HIGH. 319 5.3. Host Assigning Authority (HAA) field 321 The 63 bits of HAA supports two levels of delegation. The first is 322 a registered assigning authority (RAA). The second is a registered 323 identity (RI, commonly a company). The RAA is 23 bits with values 324 assign sequentially by ICANN. The RI is 40 bits, also assigned 325 sequentially but by the RAA. This can be used to create a 326 resolution mechanism in the DNS. For example if FOO is RAA number 327 100 and BAR is FOO's 50th registered identity, and if 329 Moskowitz 6 330 Host Identity Payload Architecture February 2000 332 1385D17FC63961F5 is the hash of the key for www.foo.com, then by 333 using DNS Binary Labels [DNSBIN] there could be a reverse lookup 334 record like: 336 \[x1385D17FC63961F5/64].\[x32/40].\[x64/23].high.int IN PTR 337 www.foo.com. 339 5.4. Endpoint Selector (ESEL) 341 ESELs (pronounced E-cells) are 32 bit localized representations of a 342 Host Identity. The purpose of an ESEL is to facilitate using Host 343 Identities in existing protocols and APIs. Each host selects its 344 own 32 bit representation for a Host Identity. It MUST be random. 345 A different ESEL SHOULD be used for each HIP exchange with a 346 particular host; this is to avoid a replay attack with an old ESEL 347 that was used as a SPI. Additionally, when a host rekeys, the ESEL 348 MUST change. One method for ESEL creation that meets these 349 criteria, would be to concatenate the HIGH with a 32 bit random 350 number, hash this (using SHA1), and then use the high order 32 bits 351 as the ESEL. 353 The owner of the Host Identity does not set its own ESEL, its 354 partner does; the risk of collisions is too great (1% in a 355 population of 10,000). Since the ESEL only has meaning to the host, 356 its generation is a local policy issue. 358 Examples of how ESELs can be used include: as the SPI in IPsec 359 (principle use, even for IPv6), as the address in a FTP command, the 360 index to address mapping in address realm gateways, and as the 361 address in a socket call. Thus ESELs act both as a bridge for Host 362 Identity into old protocols and APIs and a packet compression 363 mechanism for Host Identity in general. 365 Since rekeying changes the ESEL, a HIP implementation needs to be 366 able to handle the transition between the old and new ESEL. 368 6. Using the Host Identity 370 There are a number of ways that Host Identity can be used in 371 Internet Protocols. The first is to use it in IKE [IKE]. HIGH can 372 be used in Main Mode. For this, the Host Identity MUST be a Public 373 Key, and an appropriate Main Mode authentication (e.g. DSA 374 signature) used. The ESEL of the HIGH can replace the usage of IP 375 addresses in IKE. An appropriate ISAKMP [ISAKMP] payload will be 376 needed to accommodate the Host Identity and HIGH. These additions 377 to IKE would produce a mode of operation for IKE that could traverse 378 a NAT. This, coupled with ESP transport mode, would produce a NAT 379 friendly IPsec mode (note that the NATs can alter none of the data 380 within the ESP). 382 Moskowitz 7 383 Host Identity Payload Architecture February 2000 385 Another, and perhaps more powerful mode is a new, lightweight, 386 protocol that will allow for one host to convey its Host Identity to 387 another host. This Host Identity Protocol will enable two hosts to 388 exchange Host Identity and related information and rapidly establish 389 an ESP Security Association. It will lack the fine-grain controls 390 of IKE and some of IKE's security features (like identity 391 protection). 393 7. Mobility via HIP 395 As HIP decouples the Transport from the Internetworking layer, and 396 binds the Transport to the Host Identity (though actually either the 397 HIGH or ESEL), HIP can provide for a high degree of Internetworking 398 'mobility' at a very low infrastructure cost. HIP Internetworking 399 Mobility includes IP address changes (via any method) to either the 400 initiator or responder. Thus a system is considered mobile if its 401 IP address can change dynamically for any reason like PPP, DHCP, or 402 IPv6 TLA reassignments. 404 Initiator address changes are rather straightforward. A responder 405 CAN just accept a HIP or an ESP (whose SPI is an ESEL) packet from 406 any address and totally ignore the address for anything more than 407 packet delivery. An initiator MAY send a HIP readdress packet to 408 inform the responder of the new location of the initiator. This is 409 especially helpful for those situations where the responder is 410 sending data periodically to the initiator (that is starting a 411 connection after the initial connection). 413 Responder mobility is slightly more involved. The initiator has to 414 know where the responder is to start the HIP exchange. HIP need not 415 rely on Dynamic DNS for this function, but will use a rendezvous 416 server. The DNS address for the responder will be the address of 417 the rendezvous server. The responder will keep the rendezvous 418 server continuously updated with its IP address. The rendezvous 419 server simply forwards the initial HIP packet from the initiator to 420 the responder at its current location. All further packets are 421 between the initiator and responder, and responder mobility is 422 handled just like initiator mobility. There is very little activity 423 on the rendezvous server, responder address updates and initial HIP 424 packet forwarding, thus one server can support a large number of 425 potential responders. The responders MUST trust the rendezvous 426 server to properly maintain its HIGH and IP address mapping. 428 The responder keeps its address current on the rendezvous server by 429 setting up a HIP based SA with the rendezvous server and sending it 430 HIP Readdress packets. The rendezvous server MUST have the 431 responder's Host Identity from a trusted third party (manual, 432 DNSSEC, etc.) to avoid attacks against its HIGH and IP address 433 mapping on behalf of the responder. Further, a rendezvous server 434 will permit two mobile systems to use HIP without any extraneous 435 infrastructure, including DNSSEC if they have a method other than a 436 DNS query to get each other's HI and HIGH. 438 Moskowitz 8 439 Host Identity Payload Architecture February 2000 441 8. HIP and NATs 443 With HIP, the Transport is bound to the IP address, thus a 444 connection between two hosts can traverse many addressing realm 445 boundaries, typically implemented with Network Address Translation 446 (NAT) technology. For a HIP based flow, the NAT needs only track 447 the mapping of the HIGH or ESEL to an IP address. Many HIGHs can 448 map to a single IP address on a NAT, simplifying connections on 449 address poor NAT interfaces. The NAT can gain much of its knowledge 450 from the HIP packets themselves, however some NAT configuration MAY 451 be necessary. 453 The NAT systems CANNOT touch the datagrams within the ESP envelope, 454 thus application specific address translation MUST be done in the 455 end systems. HIP provides for 'Distributed NAT', and uses the ESEL 456 as a place holder for embedded IP addresses. See the HIP 457 Implementation document [HIPIMPL] for details. 459 8.1. HIP and TCP Checksum 461 A HIP implementation CANNOT trust the TCP checksum. There is no way 462 for an host to know if any of the IP addresses in the IP header are 463 the addresses used to calculate the TCP Checksum. Thus ALL HIP 464 implementations MUST recalculate the TCP Checksum after removing the 465 ESP envelope. 467 9. HIP Policies 469 There are a number of variables that will influence the HIP 470 exchanges that each host must support. All HIP implementations MUST 471 support at least 2 HIs, one to publish in DNS and one for anonymous 472 usage. Although anonymous HIs will be rarely used as responder HIs, 473 they will be common for initiators. Support for multiple HIs is 474 recommended. 476 Many initiators would want to use different a HI for different 477 responders. The implementations SHOULD provide for an ACL of 478 initiator HIGH to responder HIGH. This ACL SHOULD also include 479 preferred transform and local lifetimes. For HIGHs with HAAs, 480 wildcarding SHOULD be supported. Thus if a Community of Interest, 481 like Banking gets an RAA, a single ACL could be used. A global 482 wildcard would represent the general policy to be used. Policy 483 selection would be from most specific to most general. 485 Responders would need a similar ACL, representing which hosts they 486 accept HIP exchanges, and the preferred transform and local 487 lifetimes. Wildcarding SHOULD be support supported for this ACL 488 also. 490 Moskowitz 9 491 Host Identity Payload Architecture February 2000 493 10. Security Considerations 495 HIP takes advantage of the new Host Identity paradigm to provide 496 secure authentication of hosts and provide a fast key exchange for 497 IPsec ESP. HIP also attempts to limit the exposure of the host to 498 various denial-of-service (DOS) and man-in-the-middle (MITH) 499 attacks. In so doing, HIP itself is subject to its own DOS and MITM 500 attacks that potentially could be more damaging to a host's ability 501 to conduct business as usual. 503 The Security Association for ESP is indexed by the ESEL-SPI, not the 504 SPI and IP address. HIP enabled ESP is IP address independent. 505 This might seem to make it easier for an attacker, but ESP with 506 replay protection is already as well protected as possible, and the 507 removal of the IP address as a check should not increase the 508 exposure of ESP to DOS attacks. 510 Denial-of-service attacks take advantage of the cost of start of 511 state for a protocol on the responder compared to the 'cheapness' on 512 the initiator. HIP makes no attempt to increase the cost of the 513 start of state on the initiator, but makes an effort to reduce the 514 cost to the responder. This is done by having the responder start 515 the 3-way cookie exchange instead of the initiator, making the HIP 516 protocol 4 packets long. There are more details on this process in 517 the HIP protocol document [HIP]. 519 HIP optionally supports opportunistic negotiation. That is, if a 520 host receives a start of transport without a HIP negotiation, it can 521 attempt to force a HIP exchange before accepting the connection. 522 This has the potential for DOS attacks against both hosts. If the 523 method to force the start of HIP is expensive on either host, the 524 attacker need only spoof a TCP SYN. This would put both systems 525 into the expensive operations. HIP avoids this attack by having the 526 responder send a simple HIP packet that it can build at HI selection 527 time. Since this packet is fixed and easily spoofed the initiator 528 only reacts to it if it has just started a connection to the 529 responder. 531 Man-in-the-middle attacks are difficult to defend against, without 532 third-party authentication. A skillful MITM could easily handle all 533 parts of HIP; but HIP indirectly provides the following protection 534 from a MITM attack. If the responder's HI is retrieved from a 535 signed DNS zone by the initiator, the initiator can use this to 536 validate the signed HIP packets. 538 Likewise, if the initiator's HI is in a secure DNS zone, the 539 responder can retrieve it and validate the signed HIP packets. 540 However, since an initiator may choose to use an anonymous HI, it 541 knowingly risks a MITM attack. The responder may choose not to 542 accept a HIP exchange with an anonymous initiator. 544 Moskowitz 10 545 Host Identity Payload Architecture February 2000 547 Since not all hosts will ever support HIP, ICMP 'Destination 548 Protocol Unreachable' are to be expected and present a DOS attack. 549 Against an initiator, the attack would look like the responder does 550 not support HIP, but shortly after receiving the ICMP message, the 551 initiator would receive a valid HIP packet. Thus to protect against 552 this attack, an initiator should not react to an ICMP message until 553 a reasonable delta time to get the real responder's HIP packet. A 554 similar attack against the responder is more involved. 556 Another MITM attack is simulating a responder's rejection of a HIP 557 initiation. This is a simple ICMP Host Unreachable, 558 Administratively Prohibited message. A HIP packet was not used 559 because it would either have to have unique content, and thus 560 difficult to generate, resulting in yet another DOS attack, or just 561 as spoofable as the ICMP message. The defense against this MITM 562 attack is for the responder to wait a reasonable time period to get 563 a valid HIP packet. If one does not come, then the Initiator has to 564 assume that the ICMP message is valid. Since this is the only point 565 in the HIP exchange where this ICMP message is appropriate, it can 566 be ignored at any other point in the exchange. 568 10.1. HIGHs used in ACLs 570 It is expected that HIGHs will be used in ACLs. NATs will use HIGHs 571 to control egress and ingress to networks, with an assurance 572 difficult to achieve today. 574 There has been considerable bad experience with distributed ACLs 575 that contain public key related material, for example with SSH. If 576 the owner of the key needs to revoke it for any reason, the task of 577 finding all locations where the key is held in an ACL may be 578 impossible. If the reason for the revocation is due to private key 579 theft, this could be a serious issue. 581 A host can keep track of all of its partners that might use its HIGH 582 in an ACL by logging all remote HIGHs. It should only be necessary 583 to log responder hosts. With this information, the host can notify 584 the various hosts about the change to the HIGH. There has been no 585 attempt here to develop a secure method (like in CMP and CMC) to 586 issue the HIGH revocation notice. 588 NATs, however, are transparent to the HIP aware systems by design. 589 Thus the host many find it difficult to notify any NAT that is using 590 a HIGH in an ACL. Since most systems will know of the NATs for 591 their network, there should be a process by which they can notify 592 these NATs of the change of the HIGH. This is MANDITORY for systems 593 that function as responders behind a NAT. In a similar vein, if a 594 host is notified of a change in a HIGH of an initiator, it should 595 notify its NAT of the change. In this manner, NATs will get updated 596 with the HIGH change. 598 Moskowitz 11 599 Host Identity Payload Architecture February 2000 601 10.2. Non-security Considerations 603 The definition of the Host Identity states that the HI need not be a 604 public key. That the HI could be any value; for example an FQDN. 605 This document does not describe how to support a non-cryptographic 606 HI. Such a HI would still offer the services of the ESEL for NAT 607 traversal. It would carry the ESELs in an ESP that had neither 608 privacy nor authentication (ESP EMPTY). Since this mode of HIP 609 would offer so little additional functionality for so much addition 610 to the IP kernel, it has not been defined in this document. Given 611 how little public key cryptography HIP requires, HIP SHOULD only be 612 implemented using public key Host Identities. 614 11. IANA Considerations 616 The IANA considerations for HIP are covered in the Host Identity 617 payload document [HIP]. 619 12. ICANN Considerations 621 ICANN will need to set up the high.int zone and accredit the 622 registered assigning authorities (RAA) for HAA field. With 21 bits, 623 ICANN can allocate just over 2M registries. 625 13. References 627 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", RFC 2119, March 1997. 630 [HIP], Moskowitz, R., "Host Identity Payload", draft-ietf-moskowitz- 631 hip-01.txt, February 2000. 633 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 634 Payload", RFC 2406, November 1998. 636 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 637 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 638 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 640 [DNSBIN], Crawford, M., "Binary Labels in the Domain Name System", 641 RFC 2673, August 1999. 643 [IKE], Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 644 2409, November 1998. 646 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 647 "Internet Security Association and Key Management Protocol", RFC 648 2408, November 1998. 650 Moskowitz 12 651 Host Identity Payload Architecture February 2000 653 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 654 draft-ietf-moskowitz-hip-impl-00.txt, February 2000. 656 14. Acknowledgments 658 The drive to create HIP came to being after attending the MALLOC 659 meeting at IETF 43. It has matured considerably since the early 660 drafts thanks to extensive input from IETFers. Most importantly, 661 its design goals are articulated and are different from other 662 efforts in this direction. Particular mention goes to the members 663 of the NameSpace Research Group of the IRTF. Noel Chiappa provided 664 the framework for ESELs and Kieth Moore the impetuous to provide 665 resolvability. Steve Deering provided encouragement to keep 666 working, as a solid proposal can act as a proof of ideas for a 667 research group. Many others contributed; extensive security tips 668 were provided by Steve Bellovin. Rob Austein kept the DNS parts on 669 track. Rodney Thayer and Hugh Daniels provide extensive feedback. 670 John Gilmore kept me challenged to provide something of value. I 671 hope I have. 673 15. Author's Address 675 Robert Moskowitz 676 ICSA.net 677 1200 Walnut Bottom Rd. 678 Carlisle, PA 17013 679 Email: rgm@icsa.net 681 16. Copyright Statement 683 Copyright (c) The Internet Society (2000). All Rights Reserved. 684 This document and translations of it may be copied and furnished to 685 others, and derivative works that comment on or otherwise explain it 686 or assist in its implementation may be prepared, copied, published 687 and distributed, in whole or in part, without restriction of any 688 kind, provided that the above copyright notice and this paragraph 689 are included on all such copies and derivative works. However, this 690 document itself may not be modified in any way, such as by removing 691 the copyright notice or references to the Internet Society or other 692 Internet organizations, except as needed for the purpose of 693 developing Internet standards in which case the procedures for 694 copyrights defined in the Internet Standards process must be 695 followed, or as required to translate it into languages other than 696 English. 698 The limited permissions granted above are perpetual and will not be 699 revoked by the Internet Society or its successors or assigns. 701 This document and the information contained herein is provided on an 702 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 704 Moskowitz 13 705 Host Identity Payload Architecture February 2000 707 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 708 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 709 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 710 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Moskowitz 14