idnits 2.17.1 draft-moskowitz-hip-arch-02.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 1 longer page, the longest (page 1) being 890 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 (February 2001) is 8470 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 737, 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. 'RSIP' -- 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 (==), 8 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 Architecture 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. Background.........................................................3 38 5. The Host Identity..................................................4 39 5.1. Host Identity....................................................5 40 5.2. Host Identity Tag (HIT)..........................................5 41 5.2.1. Storing HIT in DNS.............................................6 42 5.3. Host Assigning Authority (HAA) field.............................6 43 5.4. Local Scope Identity (LSI).......................................7 44 5.5. Security Parameter Index (SPI)...................................7 45 5.6. Difference between an LSI and the SPI............................7 46 6. Using the Host Identity............................................8 47 7. Mobility via HIP...................................................8 48 8. HIP and NATs.......................................................9 49 8.1. HIP and TCP Checksum.............................................9 50 9. HIP Policies......................................................10 51 10. Benefits of HIP..................................................10 52 11. Security Considerations..........................................11 54 Moskowitz 1 56 Host Identity Payload Architecture February 2001 58 11.1. HITs used in ACLs..............................................13 59 11.2. Non-security Considerations....................................13 60 12. IANA Considerations..............................................13 61 13. ICANN Considerations.............................................14 62 14. References.......................................................14 63 15. Acknowledgments..................................................14 64 16. Author's Address.................................................15 65 17. Copyright Statement..............................................15 67 1. Abstract 69 This memo describes the reasoning behind proposing a new namespace, 70 the Host Identity, and a payload, between the Internetworking and 71 Transport layers, the Host layer, to carry this identity. Herein is 72 presented the basics of the current namespaces, strengths and 73 weaknesses, and how a new namespace will add completeness to them. 74 This new namespace's roles in the protocols are defined. 76 2. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in [RFC-2119]. 82 3. Introduction 84 The Internet has created two namespaces: Internet Protocol (IP) 85 addresses, and Domain Name Services (DNS) names. These two 86 namespaces have a set of features and abstractions that have powered 87 the Internet to what it is today. They also have a number of 88 weaknesses. Basically, since they are all we have, we try and do 89 too much with them. Semantic overloading and functionality 90 extensions have greatly complicated these namespaces. 92 The Host Identity (HI) namespace fills an important gap between the 93 IP and DNS namespaces. The HI is cryptographic in its nature; it is 94 the public key of an asymmetric key-pair. It is assigned to each 95 host, or technically it's networking kernel or stack. Each host 96 will have at least one HI, which can either be public (e.g. 97 published in DNS), or anonymous. Client systems will tend to have 98 both public and anonymous HIs. 100 Although the HI can be used in many authentication systems, its 101 principle design calls out for a new protocol header (HIP)_and 102 exchange [HIP] that will support trust between systems, enhance 103 mobility and dynamic IP renumbering, aid in protocol 104 translation/transition, and greatly reduce Denial Of Service (DOS) 105 attacks. 107 Moskowitz 2 109 Host Identity Payload Architecture February 2001 111 4. Background 113 The Internet is built from three principle components: Computing 114 platforms, Packet transport (i.e. internetworking) infrastructure, 115 and Services (applications). The Internet exists to service two 116 principle components: People and Robotic processes (silicon based 117 people, if you will). All these components need to be named in 118 order to interact in a scalable manner. 120 There are two principle namespaces in use in the Internet for these 121 components: IP numbers, and Domain Names. Email and SIP addresses 122 are really only an extension of Domain Names. 124 IP numbers are a confounding of two namespaces ('confounding' is a 125 term used in statistics to discuss to metrics that were merged into 126 one with a gain in indexing, but a loss in informational value), the 127 name of the networking interfaces and the routing direction vector. 128 IP numbers name networking interfaces, and typically only when the 129 interface is connected to the network. Originally IP numbers had 130 long-term significance. Today, the vast number of interfaces uses 131 ephemeral and/or non-unique IP numbers. That is ever time the 132 interface is connected to the network, it is assigned an IP number. 134 Further the transport layers are coupled to the IP addresses. 135 Neither can evolve separately from the other. IPng deliberations 136 were framed by concerns of requiring a TCPng effort as well. 138 Domain Names provide hierarchically assigned names for some 139 computing platforms and some services. Each hierarchy is delegated 140 from the level above; there is no anonymity in Domain Names. 142 Email addresses provide naming for both carbon and silicon based 143 people. Email addresses are extensions of Domain Names, only in so 144 far as a named service is responsible for managing a person's mail. 145 There is some anonymity in Email addresses. 147 There are three critical deficiencies 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. All because computing 151 platforms are not well named with the current namespaces. 153 A namespace for computing platforms can be used in end-to-end 154 operations independent of the evolution of the internetworking 155 layer and across the many internetworking layers. This could 156 support rapid readdressing of the internetworking layer either 157 from mobility or renumbering. 159 If this namespace is cryptographically based, it can also 160 provide authentication services for IPsec. If this namespace 161 is locally created without requiring registration, it can 162 provide anonymity. 164 Moskowitz 3 166 Host Identity Payload Architecture February 2001 168 Such a namespace (for computing platforms) should have the following 169 characteristics: 171 It is applied to the IP 'kernel'. The IP kernel is the 172 'component' between services and the packet transport 173 infrastructure. 175 It should fully decouple the Internetworking layer from the 176 higher layers. It should replace all occurrences of IP 177 addresses within applications (like in the TCB). This may 178 require API changes. 180 It should not mandate any infrastructure. Deployment must come 181 from the bottom up, in a pairwise deployment. 183 It should be fixed length, for easy inclusion in datagrams and 184 programming interfaces (e.g the TCB). 186 It should be affordable when used in protocols. This is 187 primarily a packet size issue. There is also a computational 188 concern in affordablity. 190 It MUST be statistically globally unique. 64 bits is 191 inadequate (1% chance of collision in a population of 640M); 192 thus approximately 128 bits should be used. 194 It should have a localized abstraction so that it can be used 195 in existing protocols and APIs. 197 It SHOULD be locally created. This can provide anonymity at 198 the cost of making resolvability very difficult. 200 Sometimes it MAY contain a delegation component. This 201 is the cost of resolvability. 203 It SHOULD provide authentication services. This is a preferred 204 function. 206 It should be long lived, but replaceable at any time. This 207 impacts access control lists; short lifetimes will tend to 208 result in tedious list maintenance or require a namespace 209 infrastructure for central control of access lists. 211 This new namespace will be called the Host Identity. It will 212 require its own protocol layer (the Host Identity Payload), between 213 the Internetworking and Transport layers. It will be based on 214 Public Key Cryptography to supply authentication services. Properly 215 designed, it can deliver all of the above stated requirements. 217 5. The Host Identity 219 Moskowitz 4 221 Host Identity Payload Architecture February 2001 223 The Host Identity represents a statistically globally unique name 224 for naming any system with an IP stack. This identity is normally 225 associated, but not limited to, an IP stack. A system can have 226 multiple identities, some 'well known', some anonymous. A system 227 may self assert its identity, or may use a third-party authenticator 228 like DNSSEC, PGP, or X.509 to 'notarize' the identity assertion. 229 DNSSEC is the MUST implement authenticator for the Host Identity. 231 Although the Host Identity can be any name that can claim 232 'statistically globally unique', a public key of a 'public key' pair 233 makes the best Host Identity. As documented in the Host Identity 234 Payload (HIP) protocol [HIP], a public key based HI can authenticate 235 the HIP packets and protect them for man-in-the-middle attacks. And 236 since authenticated datagrams are MANDITORY to provide much of HIP's 237 DOS protection, the Diffie-Hellman exchange in HIP has to be 238 authenticated. Thus only public key HI and authenticated datagrams 239 SHOULD be supported. The non-cryptographic forms of HI and HIP are 240 presented to complete the theory of HI, but SHOULD NOT be 241 implemented as they could produce worst DOS attacks than the 242 internet has without HI. 244 5.1. Host Identity 246 Host Identity adds two main features to Internet protocols. The 247 first is a decoupling of the internetworking and transport layers. 248 This decoupling will allow for independent evolution of the two 249 layers. Additionally it can provide end-to-end services over 250 multiple internetworking realms. The second feature is host 251 authentication. If the Host Identity is a public key, this key can 252 be used to authenticate security protocols like IPsec. 254 The preferred structure of the Host Identity is that of a public key 255 pair. DSA is the MUST implement algorithm for any implementation 256 supporting public keys for the Host Identity. Any other Internet 257 naming convention MAY be used for the Host Identity. However, these 258 should only be used in situations of high trust - low risk. That is 259 any place where host authentication is not needed (no risk of host 260 spoofing) and no use of IPsec. 262 The Host Identity is never directly used in any Internet protocol. 263 It may be stored in various DNS or LDAP directories as identified in 264 the HIP architecture and it is passed in the HIP payload. If the 265 Host Identity is a public key, it SHOULD be stored in a DNS KEY RR 266 with the protocol set to HIP. A Host Identity Tag (HIT) is used in 267 protocols to represent the Host Identity. Another representation of 268 the Host Identity, the Local Scope Identity (LSI) can also be used 269 in protocols and APIs. LSI's advantage over HIT is its size; its 270 disadvantage is its local scope. 272 5.2. Host Identity Tag (HIT) 274 Moskowitz 5 276 Host Identity Payload Architecture February 2001 278 The Host Identity Tag is a 128 bit field. There are two advantages 279 of using a hash over the actual Identity in protocols. First its 280 fix length makes for easier protocol coding and also better manages 281 the packet size cost of this technology. Secondly, it presents a 282 consistent format to the protocol whatever underlying identity 283 technology is used. 285 When the Host Identity is a public key, HIT functions much like the 286 SPI does in IPsec. However, instead of being an arbitrary 32-bit 287 value that, in combination with the destination IP address and 288 security protocol (ESP), uniquely identifies the Security 289 Association for a datagram, HIT identifies the public key that can 290 validate the packet authentication. HIT SHOULD be unique in the 291 whole IP universe. If there is more than one public key for a HIT, 292 the HIT acts as a hint for the correct public key to use. 294 There are two formats for HIT. Bit 0 is used to differentiate the 295 formats. If Bit 0 is zero, then the rest of HIT is a 127 bits of a 296 Hash of the key. For example, if the Identity is DSA, these bits 297 are the least significant 127 bits of the SHA-1 [FIPS-180-1] hash of 298 the DSA public key Host Identity. 300 If Bit 0 is one, then the next 63 bits is the Host Assigning 301 Authority (HAA) field, and only the last 64 bits come from a hash of 302 the Host Identity. This format for HIT is recommended for 'well 303 known' systems. It is possible to support a resolution mechanism 304 for these names in directories like DNS. Another use of HAA is in 305 policy controls. 307 The birthday paradox sets a bound for the expectation of collisions. 308 It is based on the square root of the number of values. A 64-bit 309 hash, then, would put the chances of a collision at 50-50 with 2^32 310 hosts (4 billion). A 1% chance of collision would occur in a 311 population of 640M and a .001% collision chance in a 20M population. 312 A 128 bit hash will have the same .001% collision chance in a 313 9x10^16 population. 315 5.2.1. Storing HIT in DNS 317 The HIT SHOULD be stored in DNS. The exception to this is anonymous 318 identities. The HIT is stored in a new KEY RR. The HIT KEY RR will 319 have all flags set to ZERO, its protocol set to HIP, and algorithm 320 set to HIT128. The 'public key' field of the HIT KEY RR will be the 321 128 bit HIT. 323 5.3. Host Assigning Authority (HAA) field 325 The 63 bits of HAA supports two levels of delegation. The first is 326 a registered assigning authority (RAA). The second is a registered 327 identity (RI, commonly a company). The RAA is 23 bits with values 328 assign sequentially by ICANN. The RI is 40 bits, also assigned 330 Moskowitz 6 332 Host Identity Payload Architecture February 2001 334 sequentially but by the RAA. This can be used to create a 335 resolution mechanism in the DNS. For example if FOO is RAA number 336 100 and BAR is FOO's 50th registered identity, and if 337 1385D17FC63961F5 is the hash of the key for www.foo.com, then by 338 using DNS Binary Labels [DNSBIN] there could be a reverse lookup 339 record like: 341 \[x1385D17FC63961F5/64].\[x32/40].\[x64/23].HIT.int IN PTR 342 www.foo.com. 344 5.4. Local Scope Identity (LSI) 346 LSIs are 32 bit localized representations of a Host Identity. The 347 purpose of an LSI is to facilitate using Host Identities in existing 348 protocols and APIs. The owner of the Host Identity does not set its 349 own LSI; each host selects its partner's 32 bit representation for a 350 Host Identity. It MUST be random. The risk of collisions is too 351 great (1% in a population of 10,000). Since the LSI only has 352 meaning to the host, its generation is a local policy issue. 354 One method for LSI creation that meets these criteria, would be to 355 concatenate the HIT with a 32 bit random number, hash this (using 356 SHA1), and then use the high order 32 bits as the LSI. 358 Examples of how LSIs can be used include: as the address in a FTP 359 command and as the address in a socket call. Thus LSIs act as a 360 bridge for Host Identity into old protocols and APIs. 362 5.5. Security Parameter Index (SPI) 364 SPIs are used in ESP to index into the security association 365 negotiated in HIP. The ESP SPIs have added significance when used 366 with HIP; they are a compressed representation of the HIT in every 367 packet. Thus they MAY be used by intermediary systems in providing 368 services like address mapping. A system does not set its own SPI; 369 each host selects its partner's SPI. It MUST be random. The risk 370 of collisions is too great (1% in a population of 10,000). 372 A different SPI MUST be used for each HIP exchange with a particular 373 host; this is to avoid a replay attack. Additionally, when a host 374 rekeys, the SPI MUST change. One method for SPI creation that meets 375 these criteria, would be to concatenate the HIT with a 32 bit random 376 number, hash this (using SHA1), and then use the high order 32 bits 377 as the SPI. 379 5.6. Difference between an LSI and the SPI 381 There is a subtle difference between an LSI and a SPI. 383 Moskowitz 7 385 Host Identity Payload Architecture February 2001 387 The LSI is relatively longed lived. A system selects its peer's LSI 388 and SHOULD reuse a previous LSI for a HIT during a HIP exchange. 389 The LSI ONLY appears in the 3rd and 4th HIP packets (each system 390 providing the other with its LSI). The LSI is used anywhere in 391 system processes where IP addresses have traditionally have been 392 used, like in TCBs and FTP port commands. 394 The SPI is short-lived. It changes with each HIP exchange and with 395 a HIP rekey. A system notifies its peer of the SPI to use in ESP 396 packets sent to it. Since the SPI is in all but the first two HIP 397 packets, it can be used in intermediary systems to assist in address 398 remapping. 400 6. Using the Host Identity 402 There are a number of ways that Host Identity can be used in 403 Internet Protocols. The first is to use it in IKE [IKE]. HIT can 404 be used in Main Mode. For this, the Host Identity MUST be a Public 405 Key, and an appropriate Main Mode authentication (e.g. DSA 406 signature) used. The LSI of the HIT can replace the usage of IP 407 addresses in IKE. An appropriate ISAKMP [ISAKMP] payload will be 408 needed to accommodate the Host Identity and HIT. These additions to 409 IKE would produce a mode of operation for IKE that could traverse a 410 NAT. This, coupled with ESP transport mode, would produce a NAT 411 friendly IPsec mode (note that the NATs can alter none of the data 412 within the ESP). 414 Another, and perhaps more powerful mode is a new, lightweight, 415 protocol that will allow for one host to convey its Host Identity to 416 another host. This Host Identity Protocol will enable two hosts to 417 exchange Host Identity and related information and rapidly establish 418 an ESP Security Association. It will lack the fine-grain controls 419 of IKE and some of IKE's security features (like identity 420 protection). 422 7. Mobility via HIP 424 As HIP decouples the Transport from the Internetworking layer, and 425 binds the Transport to the Host Identity (through actually either 426 the HIT or LSI), HIP can provide for a HIT degree of Internetworking 427 'mobility' at a very low infrastructure cost. HIP Internetworking 428 Mobility includes IP address changes (via any method) to either the 429 initiator or responder. Thus a system is considered mobile if its 430 IP address can change dynamically for any reason like PPP, DHCP, 431 IPv6 TLA reassignments, or a NAT remapping its translation. 433 Initiator address changes are rather straightforward. A responder 434 CAN just accept a HIP or an ESP (whose SPI is an LSI) packet from 435 any address and totally ignore the address for anything more than 436 transmitting return packets. An initiator MAY send a HIP readdress 437 packet to inform the responder of the new location of the initiator. 439 Moskowitz 8 441 Host Identity Payload Architecture February 2001 443 This is especially helpful for those situations where the responder 444 is sending data periodically to the initiator (that is starting a 445 connection after the initial connection). 447 Responder mobility is slightly more involved. The initiator has to 448 know where the responder is to start the HIP exchange. HIP need not 449 rely on Dynamic DNS for this function, but will use a rendezvous 450 server. The DNS address for the responder will be the address of 451 the rendezvous server. The responder will keep the rendezvous 452 server continuously updated with its IP address. The rendezvous 453 server simply forwards the initial HIP packet from the initiator to 454 the responder at its current location. All further packets are 455 between the initiator and responder, and responder mobility is 456 handled just like initiator mobility. There is very little activity 457 on the rendezvous server, responder address updates and initial HIP 458 packet forwarding, thus one server can support a large number of 459 potential responders. The responders MUST trust the rendezvous 460 server to properly maintain its HIT and IP address mapping. 462 The responder keeps its address current on the rendezvous server by 463 setting up a HIP based SA with the rendezvous server and sending it 464 HIP Readdress packets. The rendezvous server MUST have the 465 responder's Host Identity from a trusted third party (manual, 466 DNSSEC, etc.) to avoid attacks against its HIT and IP address 467 mapping on behalf of the responder. Further, a rendezvous server 468 will permit two mobile systems to use HIP without any extraneous 469 infrastructure, including DNSSEC if they have a method other than a 470 DNS query to get each other's HI and HIT. 472 8. HIP and NATs 474 With HIP, the Transport is bound to the LSI; thus a connection 475 between two hosts can traverse many addressing realm boundaries, 476 typically implemented with Network Address Translation (NAT) 477 technology. For a HIP based flow, the NAT needs only track the 478 mapping of the HIT or SPI to an IP address. Many HITs can map to a 479 single IP address on a NAT, simplifying connections on address poor 480 NAT interfaces. The NAT can gain much of its knowledge from the HIP 481 packets themselves, however some NAT configuration MAY be necessary. 483 The NAT systems CANNOT touch the datagrams within the ESP envelope, 484 thus application specific address translation MUST be done in the 485 end systems. HIP provides for 'Distributed NAT', and uses the LSI 486 as a place holder for embedded IP addresses. See the HIP 487 Implementation document [HIPIMPL] for details. 489 8.1. HIP and TCP Checksum 491 A HIP implementation CANNOT trust the TCP checksum. There is no way 492 for a host to know if any of the IP addresses in the IP header are 493 the addresses used to calculate the TCP Checksum. Thus ALL HIP 495 Moskowitz 9 497 Host Identity Payload Architecture February 2001 499 implementations MUST recalculate the TCP Checksum after removing the 500 ESP envelope. 502 9. HIP Policies 504 There are a number of variables that will influence the HIP 505 exchanges that each host must support. All HIP implementations MUST 506 support at least 2 HIs, one to publish in DNS and one for anonymous 507 usage. Although anonymous HIs will be rarely used as responder HIs, 508 they will be common for initiators. Support for multiple HIs is 509 recommended. 511 Many initiators would want to use a different HI for different 512 responders. The implementations SHOULD provide for an ACL of 513 initiator HIT to responder HIT. This Access Control List (ACL) 514 SHOULD also include preferred transform and local lifetimes. For 515 HITs with HAAs, wildcarding SHOULD be supported. Thus if a 516 Community of Interest, like Banking gets an RAA, a single ACL could 517 be used. A global wildcard would represent the general policy to be 518 used. Policy selection would be from most specific to most general. 520 Responders would need a similar ACL, representing which hosts they 521 accept HIP exchanges, and the preferred transform and local 522 lifetimes. Wildcarding SHOULD be support supported for this ACL 523 also. 525 10. Benefits of HIP 527 In the beginning, the network (i.e. IP) layer had the following four 528 "classic" invariants: 530 Non-mutable: The NLP sent is the NLP received (ignoring such 531 things as hop count fields---actually the only interesting 532 things are the two addresses). 534 Non-mobile: The NLP doesn't change during the course of an 535 "association". 537 Reversible: A return NLP can always be formed by reversing the 538 source and destination addresses. 540 Omniscient: Each host knows what NLP a partner host can use to 541 send packets to it. 543 Actually, the fourth can be inferred from 1 and 3, but it is worth 544 mentioning for reasons that will be obvious soon if not already. 546 In the current "post-classic" world, we are trying intentionally to 547 get rid of the second invariant (both for mobility and for 548 multihoming), and we have been forced to give up the first and the 549 fourth. RSIP [RSIP] is an attempt to reinstate the fourth invariant 551 Moskowitz 10 553 Host Identity Payload Architecture February 2001 555 without the first invariant. IPv6 is an attempt to reinstate the 556 first invariant. 558 Few systems on the Internet have DNS names, or more specifically, 559 Fully Qualified Domain Names (FQDN). FQDN names (and their 560 extensions as email names) are Application Layer names; more 561 frequently naming processes than a particular system. This is why 562 most systems on the internet are not registered in DNS; they do not 563 have processes of interest to other Internet hosts. 565 DNS names are indirect references to IP addresses. This only 566 demonstrates the interrelationship of the networking and application 567 layers. DNS, as the Internet's only deployed, distributed, database 568 is also the repository of other namespaces, due in part to DNSSEC 569 and KEY records. Although each namespace can be stretched (IP with 570 v6, DNS with KEY records), neither can adequately provide for host 571 authentication or act as a separation between Internetworking and 572 Transport layers. 574 The Host Identity (HI) namespace fills an important gap between the 575 IP and DNS namespaces. An interesting thing about the HI is that it 576 actually allows one to give-up all but the 3rd Network Layer 577 invariant. That is to say, as long as the Network Layer Protocol 578 (NLP) is reversible, then things work ok because HIP takes care of 579 host identification, and reversibility allows one to get a packet 580 back to one's partner host. You don't care if the NLP changes in 581 transit (mutable) and you don't care what NLP the partner is using 582 (non-omniscient). 584 Since all systems can have a Host Identity, every system can have an 585 entry in the DNS. The mobility features in HIP make it attractive 586 to trusted 3rd parties to offer rendezvous servers. 588 11. Security Considerations 590 HIP takes advantage of the new Host Identity paradigm to provide 591 secure authentication of hosts and provide a fast key exchange for 592 IPsec ESP. HIP also attempts to limit the exposure of the host to 593 various denial-of-service (DOS) and man-in-the-middle (MITH) 594 attacks. In so doing, HIP itself is subject to its own DOS and MITM 595 attacks that potentially could be more damaging to a host's ability 596 to conduct business as usual. 598 The Security Association for ESP is indexed by the SPI and HIT, not 599 the SPI and IP address. HIP enabled ESP is IP address independent. 600 This might seem to make it easier for an attacker, but ESP with 601 replay protection is already as well protected as possible, and the 602 removal of the IP address as a check should not increase the 603 exposure of ESP to DOS attacks. 605 Denial-of-service attacks take advantage of the cost of start of 606 state for a protocol on the responder compared to the 'cheapness' on 608 Moskowitz 11 610 Host Identity Payload Architecture February 2001 612 the initiator. HIP makes no attempt to increase the cost of the 613 start of state on the initiator, but makes an effort to reduce the 614 cost to the responder. This is done by having the responder start 615 the 3-way cookie exchange instead of the initiator, making the HIP 616 protocol 4 packets long. There are more details on this process in 617 the HIP protocol document [HIP]. 619 HIP optionally supports opportunistic negotiation. That is, if a 620 host receives a start of transport without a HIP negotiation, it can 621 attempt to force a HIP exchange before accepting the connection. 622 This has the potential for DOS attacks against both hosts. If the 623 method to force the start of HIP is expensive on either host, the 624 attacker need only spoof a TCP SYN. This would put both systems 625 into the expensive operations. HIP avoids this attack by having the 626 responder send a simple HIP packet that it can build at HI selection 627 time. Since this packet is fixed and easily spoofed the initiator 628 only reacts to it if it has just started a connection to the 629 responder. 631 Man-in-the-middle attacks are difficult to defend against, without 632 third-party authentication. A skillful MITM could easily handle all 633 parts of HIP; but HIP indirectly provides the following protection 634 from a MITM attack. If the responder's HI is retrieved from a 635 signed DNS zone by the initiator, the initiator can use this to 636 validate the signed HIP packets. 638 Likewise, if the initiator's HI is in a secure DNS zone, the 639 responder can retrieve it and validate the signed HIP packets. 640 However, since an initiator may choose to use an anonymous HI, it 641 knowingly risks a MITM attack. The responder may choose not to 642 accept a HIP exchange with an anonymous initiator. 644 Since not all hosts will ever support HIP, ICMP 'Destination 645 Protocol Unreachable' are to be expected and present a DOS attack. 646 Against an initiator, the attack would look like the responder does 647 not support HIP, but shortly after receiving the ICMP message, the 648 initiator would receive a valid HIP packet. Thus to protect against 649 this attack, an initiator should not react to an ICMP message until 650 a reasonable delta time to get the real responder's HIP packet. A 651 similar attack against the responder is more involved. 653 Another MITM attack is simulating a responder's rejection of a HIP 654 initiation. This is a simple ICMP Host Unreachable, 655 Administratively Prohibited message. A HIP packet was not used 656 because it would either have to have unique content, and thus 657 difficult to generate, resulting in yet another DOS attack, or just 658 as spoofable as the ICMP message. The defense against this MITM 659 attack is for the responder to wait a reasonable time period to get 660 a valid HIP packet. If one does not come, then the Initiator has to 661 assume that the ICMP message is valid. Since this is the only point 662 in the HIP exchange where this ICMP message is appropriate, it can 663 be ignored at any other point in the exchange. 665 Moskowitz 12 667 Host Identity Payload Architecture February 2001 669 11.1. HITs used in ACLs 671 It is expected that HITs will be used in ACLs. Firewalls will use 672 HITs to control egress and ingress to networks, with an assurance 673 difficult to achieve today. 675 [add here wildcarding] 677 There has been considerable bad experience with distributed ACLs 678 that contain public key related material, for example with SSH. If 679 the owner of the key needs to revoke it for any reason, the task of 680 finding all locations where the key is held in an ACL may be 681 impossible. If the reason for the revocation is due to private key 682 theft, this could be a serious issue. 684 A host can keep track of all of its partners that might use its HIT 685 in an ACL by logging all remote HITs. It should only be necessary 686 to log responder hosts. With this information, the host can notify 687 the various hosts about the change to the HIT. There has been no 688 attempt here to develop a secure method (like in CMP and CMC) to 689 issue the HIT revocation notice. 691 NATs, however, are transparent to the HIP aware systems by design. 692 Thus the host many find it difficult to notify any NAT that is using 693 a HIT in an ACL. Since most systems will know of the NATs for their 694 network, there should be a process by which they can notify these 695 NATs of the change of the HIT. This is MANDITORY for systems that 696 function as responders behind a NAT. In a similar vein, if a host 697 is notified of a change in a HIT of an initiator, it should notify 698 its NAT of the change. In this manner, NATs will get updated with 699 the HIT change. 701 11.2. Non-security Considerations 703 The definition of the Host Identity states that the HI need not be a 704 public key. That the HI could be any value; for example an FQDN. 705 This document does not describe how to support a non-cryptographic 706 HI. Such a HI would still offer the services of the LSI for NAT 707 traversal. It would carry the LSIs in an ESP that had neither 708 privacy nor authentication (ESP EMPTY). Since this mode of HIP 709 would offer so little additional functionality for so much addition 710 to the IP kernel, it has not been defined in this document. Given 711 how little public key cryptography HIP requires, HIP SHOULD only be 712 implemented using public key Host Identities. 714 12. IANA Considerations 716 The IANA considerations for HIP are covered in the Host Identity 717 payload document [HIP]. 719 Moskowitz 13 721 Host Identity Payload Architecture February 2001 723 13. ICANN Considerations 725 ICANN will need to set up the HIT.int zone and accredit the 726 registered assigning authorities (RAA) for HAA field. With 21 bits, 727 ICANN can allocate just over 2M registries. 729 14. References 731 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", RFC 2119, March 1997. 734 [HIP], Moskowitz, R., "Host Identity Payload", draft-ietf-moskowitz- 735 hip-02.txt, January 2001. 737 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 738 Payload", RFC 2406, November 1998. 740 [RSIP], 742 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 743 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 744 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 746 [DNSBIN], Crawford, M., "Binary Labels in the Domain Name System", 747 RFC 2673, August 1999. 749 [IKE], Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 750 2409, November 1998. 752 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 753 "Internet Security Association and Key Management Protocol", RFC 754 2408, November 1998. 756 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", 757 draft-ietf-moskowitz-hip-impl-01.txt, January 2001. 759 15. Acknowledgments 761 The drive to create HIP came to being after attending the MALLOC 762 meeting at IETF 43. It has matured considerably since the early 763 drafts thanks to extensive input from IETFers. Most importantly, 764 its design goals are articulated and are different from other 765 efforts in this direction. Particular mention goes to the members 766 of the NameSpace Research Group of the IRTF. Noel Chiappa provided 767 the framework for LSIs and Kieth Moore the impetuous to provide 768 resolvability. Steve Deering provided encouragement to keep 769 working, as a solid proposal can act as a proof of ideas for a 770 research group. Paul Francis provided much of the layering 771 architectural text. Many others contributed; extensive security 772 tips were provided by Steve Bellovin. Rob Austein kept the DNS 774 Moskowitz 14 776 Host Identity Payload Architecture February 2001 778 parts on track. Rodney Thayer and Hugh Daniels provide extensive 779 feedback. John Gilmore kept me challenged to provide something of 780 value. I hope I have. 782 16. Author's Address 784 Robert Moskowitz 785 ICSA Labs 786 1200 Walnut Bottom Rd. 787 Carlisle, PA 17013 788 Email: rgm@icsa.net 790 17. Copyright Statement 792 Copyright (c) The Internet Society (2001). All Rights Reserved. 793 This document and translations of it may be copied and furnished to 794 others, and derivative works that comment on or otherwise explain it 795 or assist in its implementation may be prepared, copied, published 796 and distributed, in whole or in part, without restriction of any 797 kind, provided that the above copyright notice and this paragraph 798 are included on all such copies and derivative works. However, this 799 document itself may not be modified in any way, such as by removing 800 the copyright notice or references to the Internet Society or other 801 Internet organizations, except as needed for the purpose of 802 developing Internet standards in which case the procedures for 803 copyrights defined in the Internet Standards process must be 804 followed, or as required to translate it into languages other than 805 English. 807 The limited permissions granted above are perpetual and will not be 808 revoked by the Internet Society or its successors or assigns. 810 This document and the information contained herein is provided on an 811 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 812 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 813 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 814 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 815 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Moskowitz 15