idnits 2.17.1 draft-moskowitz-hip-arch-00.txt: ** The Abstract section seems to be numbered -(544): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(656): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(774): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 936 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 (Dec 1999) is 8889 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- 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) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. 'EDNS') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Moskowitz, ICSA.net 2 Internet Draft 3 Document: Dec 1999 5 Host Identity Payload 6 Architecture 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 This memo describes the reasoning behind proposing a new namespace, 32 the Host Identity, and a payload, between the Internetworking and 33 Transport layers, to carry this identity. Herein is presented the 34 basics of the current namespaces, strengths and weaknesses, and how 35 a new namespace will add completeness to them. This new namespace's 36 roles in the protocols are defined. This document provides the 37 details of this namespace and protocol. 39 2. Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC-2119]. 45 3. Introduction 47 The Internet has created two namespaces: Internet Protocol (IP) 48 addresses, and Domain Name Services (DNS) names. These two 49 namespaces have a set of features and abstractions that have powered 50 the Internet to what it is today. They also have a number of 52 Moskowitz 1 53 Host Identity Payload Architecture December 1999 55 weaknesses. IP addresses define an interface, not a host and not 56 every host has one permanently, so they cannot reliably be used for 57 host authentication systems. Few systems on the Internet have DNS 58 names. DNS names are also only indirect references to IP addresses, 59 though this changes in part with DNSSEC and KEY records. Although 60 each namespace can be stretched (IP with v6, DNS with KEY records), 61 neither can adequately provide for host authentication or act as a 62 separation between Internetworking and Transport layers. 64 4. Background 66 The Internet is built from three principle components: Computing 67 platforms, Packet transport infrastructure, and Services 68 (applications). The Internet exists to service two principle 69 components: People and Robotic processes (silicon based people, if 70 you will). All these components need to be named in order to 71 interact in a scalable manner. 73 There are three principle namespaces in use in the Internet for 74 these components: IP numbers, Domain Names, and Email addresses. 76 IP addresses provide naming for the Transport Infrastructure 77 interfaces on computing platforms. IP addresses assignments are 78 centrally controlled and delegated in blocks. There is little 79 anonymity in IP addresses. IPv4 addresses provide a unique (non- 80 singular sometimes), but non-global names. IPv6 addresses MAY 81 provide globally-unique (non singular regularly?) names. Most IP 82 address assignment is transient, making IP addresses an unreliable 83 namespace outside of packet delivery. 85 Domain Names provide hierarchically assigned names for some 86 computing platforms and some services. Each hierarchy is delegated 87 from the level above; there is no anonymity in Domain Names. 89 Email addresses provide naming for both carbon and silicon based 90 people. Email addresses are extensions of Domain Names, only in so 91 far as a named service is responsible for managing a person's mail. 92 There is some anonymity in Email addresses. 94 There are three critical deficiencies with the current namespaces. 95 Computing platforms are not well named with the current namespaces. 96 Anonymity is not provided in a consistent, trustable manner. And 97 authentication is not provided. 99 A namespace for computing platforms can be used in end-to-end 100 operations independent of the evolution of the internetworking layer 101 and across the many transport layers. If this namespace is 102 cryptographically based, it can also provide authentication 103 services. If this namespace is locally created without requiring 104 registration, it can provide anonymity. 106 Moskowitz 2 107 Host Identity Payload Architecture December 1999 109 Such a namespace (for computing platforms) should have the following 110 characteristics: 112 It is applied to the IP 'kernel'. The IP kernel is the 113 'component' between services and the packet transport 114 infrastructure. 116 It should not mandate any infrastructure. Deployment must come 117 from the bottom up, in a pairwise deployment. 119 It should be fixed length. For easy inclusion in datagrams. 121 It MUST be statistically globally unique. 64 bits is 122 inadequate (1% chance of collision in a population of 640M); 123 thus approximately 128 bits should be used. 125 It SHOULD be locally created. This can provide anonymity at 126 the cost of making resolvability is very difficult. 128 Sometimes it MAY contain a delegation component. This is the 129 cost of resolvability. 131 It SHOULD provide authentication services. This is a preferred 132 function. 134 It should be long lived, but replaceable at any time. This 135 impacts access control lists; short lifetimes will tend to 136 result in tedious list maintenance or require a namespace 137 infrastructure for central control of access lists. 139 It should be affordable when used in protocols. This is 140 primarily a packet size issue. 142 It should fully decouple the Internetworking layer from the 143 higher layers. It should replace all occurrences of IP 144 addresses within applications. This may require API changes. 146 It should have a localized abstraction so that it can be used 147 in existing protocols and APIs. 149 This new namespace will be called the Host Identity. It will 150 require its own protocol layer (the Host Identity Payload), between 151 the Internetworking and Transport layers. It will be based on 152 Public Key Cryptography to supply authentication services. Properly 153 designed, it can deliver all of the above stated requirements. 155 5. Host Identity 157 The Host Identity represents a statistically globally unique name 158 for naming any system with an IP stack. This identity is normally 160 Moskowitz 3 161 Host Identity Payload Architecture December 1999 163 associated with an IP stack. A system can have multiple identities, 164 some 'well known', some anonymous. A system may self assert its 165 identity, or may use a third-party authenticator like DNSSEC, PGP, 166 or X.509 to 'notarize' the identity assertion. 168 Host Identity adds two main features to Internet protocols. The 169 first is a decoupling of the internetworking and transport layers. 170 This decoupling will allow for independent evolution of the two 171 layers. Additionally it can provide end-to-end services over 172 multiple internetworking realms. The second feature is host 173 authentication. If the Host Identity is a public key, this key can 174 be used to authenticate security protocols like IPsec. 176 The preferred structure of the Host Identity is that of a public key 177 pair. DSA is the MUST implement algorithm for any implementation 178 supporting public keys for the Host Identity. Any other Internet 179 naming convention MAY be used for the Host Identity. However, these 180 should only be used in situations of high trust - low risk. That is 181 any place where host authentication is not needed (no risk of host 182 spoofing) and no use of IPsec. 184 The Host Identity is never directly used in any Internet protocol. 185 It may be stored in various DNS or LDAP directories as identified in 186 the HIP architecture and it is passed in the HIP payload. If the 187 Host Identity is a public key, it SHOULD be stored in a DNS KEY RR 188 with the protocol set to HIP. A Host Identity Global Hash (HIGH) is 189 used in protocols to represent the Host Identity. Another 190 representation of the Host Identity, the Endpoint Selector (ESEL) 191 can also be used in protocols and APIs. ESEL's advantage over HIGH 192 is its size; its disadvantage is its local scope. 194 5.1. Host Identity Global Hash (HIGH) 196 The Host Identity Global Hash is a 128 bit field. There are two 197 advantages of using a hash over the actual Identity in protocols. 198 First its fix length makes for easier protocol coding and also 199 better manages the packet size cost of this technology. Secondly, 200 it presents a consistent format to the protocol whatever underlying 201 Identity technology is used. 203 When the Host Identity is a public key, HIGH functions much like the 204 SPI does in IPsec. However, instead of being an arbitrary 32-bit 205 value that, in combination with the destination IP address and 206 security protocol (ESP), uniquely identifies the Security 207 Association for a datagram, HIGH identifies the public key that can 208 validate the packet authentication. HIGH SHOULD be unique in the 209 whole IP universe. If there is more than one public key for a HIGH, 210 the HIGH acts as a hint for the correct public key to use. 212 There are two formats for HIGH. Bit 0 is used to differentiate the 213 formats. If Bit 0 is zero, then the rest of HIGH is a 127 bits of a 214 Hash of the key. For example, if the Identity is DSA, these bits 216 Moskowitz 4 217 Host Identity Payload Architecture December 1999 219 are the least significant 127 bits of the SHA-1 [FIPS-180-1] hash of 220 the DSA public key Host Identity. 222 If Bit 0 is one, then the next 63 bits is the Host Assigning 223 Authority field, and only the last 64 bits come from a hash of the 224 Host Identity. This format for HIGH is recommended for 'well known' 225 systems. It is possible to support a resolution mechanism for these 226 names in directories like DNS. 228 The birthday paradox sets a bound for the expectation of collisions. 229 It is based on the square root of the number of values. A 64-bit 230 hash, then, would put the chances of a collision at 50-50 with 2^32 231 hosts (4 billion). A 1% chance of collision would occur in a 232 population of 640M and a .001% collision chance in a 20M population. 233 A 128 bit hash will have the same .001% collision chance in a 234 9x10^16 population. 236 5.1.1. Storing HIGH in DNS 238 The HIGH SHOULD be stored in DNS. The exception to this is 239 anonymous identities. The HIGH is stored in a new KEY RR. The HIGH 240 KEY RR will have all flags set to ZERO, its protocol set to HIP, and 241 algorithm set to HIGH128. The 'public key' field of the HIGH KEY RR 242 will be the 128 bit HIGH. 244 5.2. Host Assigning Authority (HAA) field 246 The 63 bits of HAA supports two levels of delegation. The first is 247 a registered assigning authority (RAA). The second is a registered 248 identity (RI, commonly a company). The RAA is 23 bits with values 249 assign sequentially by ICANN. The RI is 40 bits, also assigned 250 sequentially but by the RAA. This can be used to create a 251 resolution mechanism in the DNS. For example if FOO is RAA number 252 100 and BAR is FOO's 50th registered identity, and if 253 1385D17FC63961F5 is the hash of the key for www.foo.com, then by 254 using DNS Binary Labels [DNSBIN] there could be a reverse lookup 255 record like: 257 \[x1385D17FC63961F5/64].50.100.high.int IN PTR www.foo.com. 259 5.3. Endpoint Selector (ESEL) 261 ESELs are 32 bit localized representations of a Host Identity. The 262 purpose of an ESEL is to facilitate using Host Identities in 263 existing protocols and APIs. Each host selects its own 32 bit 264 representation for a Host Identity. It SHOULD be random, it COULD 265 be sequential if security systems will not be relying on it. The 266 owner of the Host Identity does not set its ESEL; the risk of 267 collisions is too great (1% in a population of 10,000). Since the 269 Moskowitz 5 270 Host Identity Payload Architecture December 1999 272 ESEL only has meaning to the host, its generation is a local policy 273 issue. 275 Examples of how ESELs can be used include: as the SPI in IPsec, as 276 the destination IP address inside a IP tunnel, as the address in a 277 FTP command, and as the address in a socket call. Thus ESELs act 278 both as a bridge for Host Identity into old protocols and APIs and a 279 packet compression mechanism for Host Identity in general. 281 5.4. Using ESELs in place of IP addresses 283 ESELs can be used in place of IP addresses in socket calls. This 284 can be accommodated with the aid of a modified resolver module. 285 When a HIP exchange produces, and exchanges the ESELs, either the 286 ESEL can be provided to the applications in place of the IP 287 addresses and then the HIP module perform any substitution required, 288 or the HIP module can intercept all address requests and use the 289 ESEL where appropriate. 291 At issue here is when do applications get IP addresses, and where do 292 they use them. The ESELs are not established until the 3rd and 4th 293 HIP packets, which may be too late for some applications. If the 294 applications are using IP addresses within their data stream (as FTP 295 commands do), the HIP module will have to perform tasks similar to a 296 NAT to find these addresses and replace them with the appropriate 297 ESEL. 299 If the applications are using ESELs (as could be the case on 300 subsequent connections during the lifetime of the HIP state), then 301 the HIP module directs opens to ESELs to the appropriate IP address. 302 The HIP module would not need to perform NAT functions on imbedded 303 IP addresses. 305 6. Using the Host Identity 307 There are a number of ways that Host Identity can be used in 308 Internet Protocols. The first is to use it in IKE [IKE]. HIGH can 309 be used in Main Mode. For this, the Host Identity MUST be a Public 310 Key, and an appropriate Main Mode authentication (e.g. DSA 311 signature) used. The ESEL of the HIGH can replace the usage of IP 312 addresses in IKE. An appropriate ISAKMP [ISAKMP] payload will be 313 needed to accommodate the Host Identity and HIGH. These additions 314 to IKE would produce a mode of operation for IKE that could traverse 315 a NAT. This, coupled with ESP transport mode, would produce a NAT 316 friendly IPsec mode (note that the NATs can alter none of the data 317 within the ESP). 319 Another, and perhaps more powerful mode is a new, lightweight, 320 protocol that will allow for one host to convey its Host Identity to 321 another host. This Host Identity Protocol will enable two hosts to 322 exchange Host Identity and related information and rapidly establish 324 Moskowitz 6 325 Host Identity Payload Architecture December 1999 327 an ESP Security Association. It will lack the fine-grain controls 328 of IKE and some of IKE's security features (like identity 329 protection). 331 7. The Host Identity Payload 333 The goal of the Host Identity Payload or HIP is to provide for a 334 host identity, in most cases a trustable identity, in every IP 335 datagram (see below for HIP packet compression). This identity can 336 be used to enable IPsec to provide authenticity and privacy. HIP 337 can supply the Host Identity for NAT state functions. 339 HIP can be used as an alternative to IKE when fine-grain controls 340 are not needed. In fact, HIP SHOULD be used with IPsec to bind its 341 identity to the datagram. HIP can make protocols like IPsec's ESP 342 NAT friendly. There is nothing in HIP that is tied to an IP 343 address. Of course the ESP payload can have imbedded IP addresses 344 that, since authenticated, cannot be altered by a NAT. 346 7.1. HIP format 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Next Header | Payload Len | RESERVED | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 | Host Identity Global Hash (HIGH) | 355 | | 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 | HIP Key payload | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | ESP followed by IP payload (opt) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 7.2. HIP Key Payload 367 The HIP Key Payload is used to carry the public key associated with 368 the HIGH and related security information. The format of the HIP 369 Key Payload is a simplification of a DNS message [DNS]. Since only 370 the answer portion of a message is needed, the payload consists of 371 ANCOUNT field of the message header followed by the indicated number 372 of resource records. 374 The resource records will either be a KEY (e.g. DSA and D-H), SIG 375 [DNSSEC], or OPT [EDNS] record. The first resource record in the 377 Moskowitz 7 378 Host Identity Payload Architecture December 1999 380 HIP payload will contain the host's FQDN, if it has one, otherwise 381 this field will be null. All other resource records for the host 382 will use message compression. The RDATA of the OPT record in the 383 payload can contain any of the following: 385 OPT Attribute Length Data 387 Remotes_HIGH 128 Remote's HIGH 388 HIP_COOKIE 192 3 64 bit fields: 389 Random #, either I or J 390 SHA1(random#, I) truncated 391 F(I,J) (zero in 1st 2 cookies) 392 HIP_TRANSFORM variable ISAKMP Transform [ISAKMP] 393 Without first 32 bits 394 Using Ipsec DOI 395 Remotes_ESEL 32 Remote's ESEL 397 7.3. HIP Rekey Payload 399 During the life of an Security Association established by HIP, one 400 of the hosts may need to rekey. The reason for rekeying might be a 401 sequence number rap in ESP, or a local policy on use of a key. The 402 Rekey Payload permits a host to change its Diffie-Hellman key and 403 thus the keying material for ESP. The Rekey Payload is a HIP packet 404 with only a Diffie-Hellman RR in the HIP payload. The HIP packet is 405 transported within the ESP to provide authentication of the 406 rekeying; there is no next protocol in the HIP packet. Thus the 407 datagram looks like: 409 IP[ESP[HIP(D-H)]] 411 When a host receives a Rekey Payload, its next ESP packet MUST use 412 the KEYMAT generated by the new Kij. The sending host MUST expect 413 at least a sequence number replay window worth of ESP packets using 414 the old Kij. Out of order delivery could result in needing the old 415 Kij after packets start arriving using the new Kij. Once past the 416 rekeying start, the sending host can drop the old Kij. 418 8. HIP Scenarios 420 There are a number of scenarios for using HIP. The variables in 421 these scenarios are the number of address realms (managed by NATs) 422 and the jurisdictional location of the boundaries, and the type of 423 Host Identity (public key or string like an FQDN). 425 8.1. HIP Scenario #1 427 Initiator and Responder in common addressing realm (i.e. both public 428 or both private). 430 Moskowitz 8 431 Host Identity Payload Architecture December 1999 433 Initiator gets IP address of Responder somehow. 434 Hard coded (bad) 435 DNS lookup 436 DNSSEC important 437 A HIP aware client should always retrieve HIP records 438 too. The default DNS records would be a DSA 439 and HIGH KEY RR with protocol of HIP. This is 440 important for the Initiator to validate packet 441 #3. 443 I --> DNS (lookup R) 444 I <-- DNS (R's info) 445 I --> R (Hi, let's talk HIP) 446 I <-- R (OK, handle this HIP cookie) 447 I --> R (Compute, compute, here is my counter HIP with ESP protected 448 data) 449 I <-- R (OK, Let�s finish HIP cookie, and here is my ESP protected 450 data) 452 Initiator sends first packet with HIP 453 HIP Includes: HIGH, [Responder's HIGH (from DNS query)] 454 Next protocol = 0 456 Responder sends first packet with HIP 457 HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, 458 HIP_TRANSFORM, and SIG 459 If multiple HI, match Initiator's request 460 HIP_COOKIE contains random I 461 I is internal pointer to DH 462 HIP_DH is ephemeral, but can be reused 463 Scavenger cleans up unused DHs and Is 464 HIP_TRANSFORM contains the ESP modes supported by the 465 responder 466 SIG calculated over whole HIP 467 Next protocol = 0 469 Must keep state on I and DH pair. Can reduce costs in event of 470 a DOS attack by using the same DH for a number of connects over 471 some time. Additionally, the same I might be used if a large 472 number of attempts come from different addresses in a short 473 time (classic DOS attack). Initiator must validate the HIP 474 SIG, minimally with included HI. If HI is received during 475 initial DNS query, this should be used. 477 Initiator sends second packet with HIP 478 HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, 479 HIP_TRANSFORM, and SIG 480 HIP_COOKIE contains random J and Hash(current_secret, 481 I). J is internal pointer to DH 482 HIP_DH is ephemeral, but can be reused 483 Scavenger cleans up unused DHs and Js 484 The ESEL will become the ESP SPI 485 HIP_TRANSFORM contains selected ESP algorithms 487 Moskowitz 9 488 Host Identity Payload Architecture December 1999 490 SIG calculated over whole HIP 491 Next Protocol is ESP 492 Optional encryption and mandatory auth 493 Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 494 SPI is the Responder's ESEL of the Initiator, but don't 495 have ESEL yet, so 1st packet uses SPI = Random 496 # 497 ESP payload is first data gram 499 Must keep state of I, J, DH pair, and Responder's DH, ESEL and 500 ESP TRANSFORM used. 502 Responder sends second, and last, packet with HIP 503 HIP Includes: HIP_COOKIE, Initiator ESEL and SIG 504 The ESEL will become the ESP SPI 505 HIP_COOKIE contains random I, Hash(current_secret, I), 506 and F(I,J) 507 Next Protocol is ESP 508 SPI is the Initiator's ESEL of the Responder 509 ESP payload is data gram 511 Must keep state of DH pair, and Initiator's DH, ESEL and ESP 512 TRANSFORM used. 514 All further packets are without HIP, HIP is implied with the SPIs = 515 ESELs --> HIGH 517 8.2. HIP Scenario #2 519 Initiator behind NAT, Responder publicly addressed. 521 Initiator gets IP address of Responder somehow. 522 Hard coded (bad) 523 DNS lookup 524 DNSSEC important 525 A HIP aware client should always retrieve HIP records 526 too. The default DNS records would be a DSA 527 and HIGH KEY RR with protocol of HIP. This is 528 important for the Initiator to validate packet 529 #3. 530 If no default route to NAT, DNS ALG provides NAT with 531 Responder's IP address and HIGH; NAT provides 532 DNS ALG with substitute internal address. 534 I --> NAT(I) --> DNS (lookup R) 535 I <-- NAT(I) <-- DNS (R's info, record it in NAT) 536 I --> NAT(I) --> R (Hi, let's talk HIP) 537 I <-- NAT(I) <-- R (OK, handle this HIP cookie) 538 I --> NAT(I) --> R (Compute, compute, here is my counter HIP with 539 ESEL(R) and ESP protected data) 541 Moskowitz 10 542 Host Identity Payload Architecture December 1999 544 I <-- NAT(I) <-- R (OK, Let�s finish HIP cookie, and here is ESEL(I) 545 and my ESP protected data) 547 Initiator sends first packet with HIP 548 HIP Includes: HIGH, [Responder's HIGH (from DNS query)] 549 Next protocol = 0 550 NAT records Initiator's HIGH and address makes address changes 551 in IP header 553 Responder sends first packet with HIP 554 HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, 555 HIP_TRANSFORM, and SIG 556 If multiple HI, match Initiator's request 557 HIP_COOKIE contains random I 558 I is internal pointer to DH 559 HIP_DH is ephemeral, but can be reused 560 Scavenger cleans up unused DHs and Is 561 HIP_TRANSFORM contains the ESP modes supported by the 562 responder 563 SIG calculated over whole HIP 564 Next protocol = 0 566 Must keep state on I and DH pair. Can reduce costs in event of 567 a DOS attack by using the same DH for a number of connects over 568 some time. Additionally, the same I might be used if a large 569 number of attempts come from different addresses in a short 570 time (classic DOS attack). Initiator must validate the HIP 571 SIG, minimally with included HI. If HI is received during 572 initial DNS query, this should be used. 573 NAT changes addresses based on HIGHs in HIP. 575 Initiator sends second packet with HIP 576 HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, 577 HIP_TRANSFORM, and SIG 578 HIP_COOKIE contains random J and Hash(current_secret, 579 I). J is internal pointer to DH 580 HIP_DH is ephemeral, but can be reused 581 Scavenger cleans up unused DHs and Js 582 The ESEL will become the ESP SPI 583 HIP_TRANSFORM contains selected ESP algorithms 584 SIG calculated over whole HIP 585 Next Protocol is ESP 586 Optional encryption and mandatory auth 587 Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 588 SPI is the Responder's ESEL of the Initiator, but don't 589 have ESEL yet, so 1st packet uses SPI = Random 590 # 591 ESP payload is first data gram 593 Must keep state of I, J, DH pair, and Responder's DH, ESEL and 594 ESP TRANSFORM used. 595 NAT adds Initiator's Responder ESEL to I/R state and changes 596 addresses. 598 Moskowitz 11 599 Host Identity Payload Architecture December 1999 601 Responder sends second, and last, packet with HIP 602 HIP Includes: HIP_COOKIE, Initiator ESEL and SIG 603 The ESEL will become the ESP SPI 604 HIP_COOKIE contains random I, Hash(current_secret, I), 605 and F(I,J) 606 Next Protocol is ESP 607 SPI is the Initiator's ESEL of the Responder 608 ESP payload is data gram 610 Must keep state of DH pair, and Initiator's DH, ESEL and ESP 611 TRANSFORM used. 612 NAT adds Responder's Initiator ESEL to I/R state and changes 613 addresses. 615 All further packets are without HIP, HIP is implied with the SPIs = 616 ESELs --> HIGH 617 NAT uses ESELs for address state. 618 Hosts use ESELs in place of IP addresses inside protocols. 619 E.G. Initiator uses Responder's Initiator ESEL (packet 4) for 620 FTP port command. Responder is able to remap this to state it has 621 on Initiator. 623 8.3. HIP Scenario #3 625 Initiator publicly addressed, Responder behind NAT. 627 NAT configured with Responder's IP address and HIGH. DNS for the 628 responder will have the NAT's address. 630 Initiator gets IP address of Responder (NAT) somehow. 631 Hard coded (bad) 632 DNS lookup 633 DNSSEC important 634 A HIP aware client should always retrieve HIP records 635 too. The default DNS records would be a DSA 636 and HIGH KEY RR with protocol of HIP. This is 637 important for the Initiator to validate packet 638 #3. 639 If no default route to NAT, NAT maps Initiator's HIGH 640 and ESEL to an internal address. Since the 641 ESEL has to be used after HIP exchange, and 642 ESEL is on a host basis, the Initiator will use 643 a separate internal address for each internal 644 host. 646 I --> DNS (lookup R, get NAT's address and R's HIGH) 647 I <-- DNS (R's info) 648 I --> NAT(R) --> R (Hi, let's talk HIP) 649 I <-- NAT(R) <-- R (OK, handle this HIP cookie) 651 Moskowitz 12 652 Host Identity Payload Architecture December 1999 654 I --> NAT(R) --> R (Compute, compute, here is my counter HIP with 655 ESEL(R) and ESP protected data) 656 I <-- NAT(R) <-- R (OK, Let�s finish HIP cookie, and here is ESEL(I) 657 and my ESP protected data) 659 Initiator sends first packet with HIP 660 HIP Includes: HIGH, Responder's HIGH (from DNS query) 661 Next protocol = 0 662 NAT records Initiator's HIGH and address makes address changes 663 in IP header. Uses Responder's HIGH to map to 664 responder. 666 Responder sends first packet with HIP 667 HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, 668 HIP_TRANSFORM, and SIG 669 If multiple HI, match Initiator's request 670 HIP_COOKIE contains random I 671 I is internal pointer to DH 672 HIP_DH is ephemeral, but can be reused 673 Scavenger cleans up unused DHs and Is 674 HIP_TRANSFORM contains the ESP modes supported by the 675 responder 676 SIG calculated over whole HIP 677 Next protocol = 0 679 Must keep state on I and DH pair. Can reduce costs in event of 680 a DOS attack by using the same DH for a number of connects over 681 some time. Additionally, the same I might be used if a large 682 number of attempts come from different addresses in a short 683 time (classic DOS attack). Initiator must validate the HIP 684 SIG, minimally with included HI. If HI is received during 685 initial DNS query, this should be used. 686 NAT changes addresses based on HIGHs in HIP. 688 Initiator sends second packet with HIP 689 HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, 690 HIP_TRANSFORM, and SIG 691 HIP_COOKIE contains random J and Hash(current_secret, 692 I). J is internal pointer to DH 693 HIP_DH is ephemeral, but can be reused 694 Scavenger cleans up unused DHs and Js 695 The ESEL will become the ESP SPI 696 HIP_TRANSFORM contains selected ESP algorithms 697 SIG calculated over whole HIP 698 Next Protocol is ESP 699 Optional encryption and mandatory auth 700 Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 701 SPI is the Responder's ESEL of the Initiator, but don't 702 have ESEL yet, so 1st packet uses SPI = Random 703 # 704 ESP payload is first data gram 706 Moskowitz 13 707 Host Identity Payload Architecture December 1999 709 Must keep state of I, J, DH pair, and Responder's DH, ESEL and 710 ESP TRANSFORM used. 711 NAT adds Initiator's Responder ESEL to I/R state and changes 712 addresses. The NAT will have one responder HIGH to address 713 state, but potentially many responder ESEL to address state. 715 Responder sends second, and last, packet with HIP 716 HIP Includes: HIP_COOKIE, Initiator ESEL and SIG 717 The ESEL will become the ESP SPI 718 HIP_COOKIE contains random I, Hash(current_secret, I), 719 and F(I,J) 720 Next Protocol is ESP 721 SPI is the Initiator's ESEL of the Responder 722 ESP payload is data gram 724 Must keep state of DH pair, and Initiator's DH, ESEL and ESP 725 TRANSFORM used. 726 NAT adds Responder's Initiator ESEL to I/R state and changes 727 addresses. 729 All further packets are without HIP, HIP is implied with the SPIs = 730 ESELs --> HIGH 731 NAT uses ESELs for address state. 732 Hosts use ESELs in place of IP addresses inside protocols. 733 E.G. Initiator uses Responder's Initiator ESEL (packet 4) for 734 FTP port command. Responder is able to remap this to state it has 735 on Initiator. 737 8.4. HIP Scenario #4 739 Initiator and Responder behind separate NATs. 741 NAT configured with Responder's IP address and HIGH. DNS for the 742 responder will have the NAT's address. 744 Initiator gets IP address of Responder (NAT) somehow. 745 Hard coded (bad) 746 DNS lookup 747 DNSSEC important 748 A HIP aware client should always retrieve HIP records 749 too. The default DNS records would be a DSA 750 and HIGH KEY RR with protocol of HIP. This is 751 important for the Initiator to validate packet 752 #3. 753 If no default route to initiator's NAT, DNS ALG 754 provides NAT with Responder's IP address and 755 HIGH; NAT provides DNS ALG with substitute 756 internal address. 757 If no default route to responder's NAT, NAT maps 758 Initiator's HIGH and ESEL to an internal 759 address. Since the ESEL has to be used after 761 Moskowitz 14 762 Host Identity Payload Architecture December 1999 764 HIP exchange, and ESEL is on a host basis, the 765 Initiator will use a separate internal address 766 for each internal host. 768 I --> NAT(I) --> DNS (lookup R, get NAT's address and R's HIGH) 769 I <-- NAT(I) <-- DNS (R's info, record it in NAT) 770 I --> NAT(I) --> NAT(R) --> R (Hi, let's talk HIP) 771 I <-- NAT(I) <-- NAT(R) <-- R (OK, handle this HIP cookie) 772 I --> NAT(I) --> NAT(R) --> R (Compute, compute, here is my counter 773 HIP with ESEL(R) and ESP protected data) 774 I <-- NAT(I) <-- NAT(R) <-- R (OK, Let�s finish HIP cookie, and here 775 is ESEL(I) and my ESP protected data) 777 Initiator sends first packet with HIP 778 HIP Includes: HIGH, Responder's HIGH (from DNS query) 779 Next protocol = 0 780 Initiator's NAT records Initiator's HIGH and address makes 781 address changes in IP header 782 Responder's NAT records Initiator's HIGH and address makes 783 address changes in IP header. Uses Responder's HIGH to 784 map to responder. 786 Responder sends first packet with HIP 787 HIP Includes: HI, Initiator's HIGH, HIP_COOKIE, HIP_DH, 788 HIP_TRANSFORM, and SIG 789 If multiple HI, match Initiator's request 790 HIP_COOKIE contains random I 791 I is internal pointer to DH 792 HIP_DH is ephemeral, but can be reused 793 Scavenger cleans up unused DHs and Is 794 HIP_TRANSFORM contains the ESP modes supported by the 795 responder 796 SIG calculated over whole HIP 797 Next protocol = 0 799 Must keep state on I and DH pair. Can reduce costs in event of 800 a DOS attack by using the same DH for a number of connects over 801 some time. Additionally, the same I might be used if a large 802 number of attempts come from different addresses in a short 803 time (classic DOS attack). Initiator must validate the HIP 804 SIG, minimally with included HI. If HI is received during 805 initial DNS query, this should be used. 806 Both NATs changes addresses based on HIGHs in HIP. 808 Initiator sends second packet with HIP 809 HIP Includes: HI, Responder HIGH and ESEL, HIP_COOKIE, HIP_DH, 810 HIP_TRANSFORM, and SIG 811 HIP_COOKIE contains random J and Hash(current_secret, 812 I). J is internal pointer to DH 813 HIP_DH is ephemeral, but can be reused 814 Scavenger cleans up unused DHs and Js 815 The ESEL will become the ESP SPI 816 HIP_TRANSFORM contains selected ESP algorithms 818 Moskowitz 15 819 Host Identity Payload Architecture December 1999 821 SIG calculated over whole HIP 822 Next Protocol is ESP 823 Optional encryption and mandatory auth 824 Kij used from KEYMAT, Default is 3DES, HMAC-SHA1 825 SPI is the Responder's ESEL of the Initiator, but don't 826 have ESEL yet, so 1st packet uses SPI = Random 827 # 828 ESP payload is first data gram 830 Must keep state of I, J, DH pair, and Responder's DH, ESEL and 831 ESP TRANSFORM used. 832 Initiator's NAT adds Initiator's Responder ESEL to I/R state 833 and changes addresses. 834 Responder's NAT adds Initiator's Responder ESEL to I/R state 835 and changes addresses. The NAT will have one responder HIGH to 836 address state, but potentially many responder ESEL to address 837 state. 839 Responder sends second, and last, packet with HIP 840 HIP Includes: HIP_COOKIE, Initiator ESEL and SIG 841 The ESEL will become the ESP SPI 842 HIP_COOKIE contains random I, Hash(current_secret, I), 843 and F(I,J) 844 Next Protocol is ESP 845 SPI is the Initiator's ESEL of the Responder 846 ESP payload is data gram 848 Must keep state of DH pair, and Initiator's DH, ESEL and ESP 849 TRANSFORM used. 850 NAT adds Responder's Initiator ESEL to I/R state and changes 851 addresses. 853 All further packets are without HIP, HIP is implied with the SPIs = 854 ESELs --> HIGH 855 Both NATs uses ESELs for address state. 856 Hosts use ESELs in place of IP addresses inside protocols. 857 E.G. Initiator uses Responder's Initiator ESEL (packet 4) for 858 FTP port command. Responder is able to remap this to state it has 859 on Initiator. 861 8.5. Refusing a HIP exchange 863 A HIP aware host may choose not to accept a HIP exchange 864 negotiation. If the host's policy is to only be an initiator, it 865 should begin its own HIP exchange. There is a risk of a race 866 condition if each host's policy is to only be an initiator, at which 867 point the HIP exchange will fail. 869 If the host's policy does not permit it to enter into a HIP exchange 870 with the initiator, it should send an ICMP Host Unreachable, 871 Administratively Prohibited message. A more complex HIP packet is 873 Moskowitz 16 874 Host Identity Payload Architecture December 1999 876 not used here as it actually opens up more potential DOS attacks 877 than a simple ICMP message. 879 9. ESP with HIP 881 HIP sets up a Security Association (SA) to enable ESP in an end-to- 882 end manner that can span addressing realms (i.e. across NATs). This 883 is accomplished through the various information that is exchanged 884 within HIP. It is anticipated that since HIP is designed for host 885 usage, that is not for gateways, that only ESP transport mode will 886 be supported with HIP. The SA is not bound to an IP address, all 887 internal control of the SA is by the HIGH and ESEL. Thus a host can 888 easily change its address using Mobile IP, DHCP, or PPP and still 889 maintain the SA. So real-world conditions like loss of a PPP 890 connection and its reestablishment will not require a HIP 891 negotiation. 893 Since HIP does not negotiate any lifetimes, all lifetimes are local 894 policy. The only lifetimes a HIP implementation MUST support are 895 sequence number rollover (for replay protection), and SA timeout. 896 An SA times out when no packets are received using that SA. The 897 default timeout value is 15 minutes. Implementations MAY support 898 lifetimes for the various ESP transforms. Note that HIP does not 899 offer any service comparable with IKE's Quick Mode. A Diffie- 900 Hellman calculation is needed for each rekeying. 902 9.1. Security Parameters Index (SPI) 904 HIP uses the ESELs as the SPIs in ESP. This provides simple 905 compression of the HIP data from all packets after the HIP exchange. 906 The very first ESP packet from the Initiator occurs before the 907 Initiator has the ESEL from the Responder. For this packet a random 908 number is used. The Responder will have to maintain the relation of 909 that random number to the ESEL, so that when the next packet from 910 the Initiator with the ESEL for the SPI arrives, the Responder 911 recognizes that this is the same SA. 913 This does result in a per host-pair SPI, and a decrease of policy 914 granularity over other KMPs like IKE. 916 9.2. Sequence Number 918 The Sequence Number field is MANDATORY in ESP [ESP]. Anti-replay 919 protection MUST be used in an ESP SA established with HIP. 921 This means that each host MUST rekey before its sequence number 922 reaches 2^32. Note that in HIP rekeying, unlike IKE rekeying, only 923 one Diffie-Hellman key is changed, that of the rekeying host. Thus 924 if one host rekeys, the other host SHOULD rekey as well. 926 Moskowitz 17 927 Host Identity Payload Architecture December 1999 929 9.3. Sequence Number State Machine 931 Ioo Initiator at no data packets sent, none received 932 Roo Responder at no data packets sent, none received 933 I1 or R1 Initial HIP packet from Host 934 I2 or R2 Second HIP with data packet from Host 935 Iesp or Resp Data packet from Host 936 Inm or Rnm host sent packet n, and received packet m 938 +---------+ 939 | Ioo,Roo |<----------------------------+ 940 +---------+ | 941 | | 942 | I1->R | 943 | | 944 v | 945 +---------+ | 946 | Ioo,Roo | | 947 +---------+ | 948 | | 949 | R1->I | 950 | | 951 v | After I receives 952 +---------+ | x ICMPs 953 | Ioo,Roo | | 954 +---------+ | 955 | | 956 | I2->R | 957 | | 958 v | 959 +---------+ I2->R +---------+ | 960 | I1o,Ro1 |<-----------| Ioo,Rmn | | 961 +---------+ +---------+ | 962 | ^ | 963 | R2->I | R1->I | 964 | | | 965 v | | 966 +---------+ +---------+ | 967 | I11,R11 | | Ioo,Rmn | | 968 +---------+ +---------+ | +---------+ 969 | ^ | | Inm,Roo |-+ 970 | ESP | I1->R | +---------+ | 971 | Packets | | ^ | 972 v I reboots +---------+ | | Iesp->R | Ricmp 973 +---------+ ---------->| Ioo,Rmn | | | | ->I 974 +->| Inm,Rmn | or timeout +---------+ +---------+ | 975 | +---------+ -------------------------->| Inm,Roo |<---+ 976 | | | ^ R reboots +---------+ 977 |ESP | | +------+ or timeout 978 |Pckt|Rrky|Irky | 980 Moskowitz 18 981 Host Identity Payload Architecture December 1999 983 | |->I |->R |ESP 984 | | +----+ |packet 985 | v v | 986 +---------+ +---------+ 987 | In1,R1n | | I1m,Rm1 | {rekeying states} 988 +---------+ +---------+ 990 10. Security Considerations 992 HIP is designed to provide secure authentication of hosts and 993 provide a fast key exchange for IPsec ESP. HIP also attempts to 994 limit the exposure of the host to various denial-of-service and man- 995 in-the-middle attacks. In so doing, HIP itself is subject to its 996 own DOS and MIM attacks that potentially could be more damaging to a 997 host's ability to conduct business as usual. 999 The Security Association for ESP is indexed by the ESEL-SPI, not the 1000 SPI and IP address. HIP enabled ESP is IP address independent. 1001 This might seem to make it easier for an attacker, but ESP with 1002 replay protection is already as well protected as possible, and the 1003 removal of the IP address as a check should not increase the 1004 exposure of ESP to DOS attacks. 1006 Denial-of-service attacks take advantage of the cost of start of 1007 state for a protocol on the responder compared to the 'cheapness' on 1008 the initiator. HIP makes no attempt to increase the cost of the 1009 start of state on the initiator, but makes an effort to reduce the 1010 cost to the responder. This is done by having the responder start 1011 the 3-way cookie exchange instead of the initiator, making the HIP 1012 protocol 4 packets long. 1014 This shifting of the start of state cost to the initiator in 1015 creating the I2 HIP packet, presents another DOS attack. The 1016 attacker spoofs the I1 HIP packet and the responder sends out the R1 1017 HIP packet. This could conceivably tie up the 'initiator' with 1018 evaluating the R1 HIP packet, and creating the I2 HIP packet. The 1019 defense against this attack is to simply ignore any R1 packet where 1020 a corresponding I1 was not sent. 1022 A second form of DOS attack is emulating the restart of state after 1023 a reboot of one of the partners. To protect against such an attack 1024 on the responder, it should send reply to an I1 HIP packet without 1025 resetting its state. Only on receipt of an I2 HIP packet within a 1026 reasonable delta after sending its R1 HIP packet, should the 1027 responder reset its state. An initiator protects itself be ignoring 1028 any R1 or R2 packets while it has state with R. 1030 A third form of DOS attack is emulating the end of state. HIP has 1031 no end of state packet. It relies on a local policy timer to end 1032 state. 1034 Moskowitz 19 1035 Host Identity Payload Architecture December 1999 1037 Man-in-the-middle attacks are difficult to defend against, without 1038 third-party authentication. A skillful MIM could easily handle all 1039 parts of HIP; but HIP indirectly provides the following protection 1040 from a MIM attack. If the responder's HI is retrieved from a signed 1041 DNS zone by the initiator, the initiator can use this to validate 1042 the R1 HIP packet. 1044 Likewise, if the initiator's HI is in a secure DNS zone, the 1045 responder can retrieve it after it gets the I2 HIP packet and 1046 validate that. However, since an initiator may choose to use an 1047 anonymous HI, it knowingly risks a MIM attack. The responder may 1048 choose not to accept a HIP exchange with an anonymous initiator. 1050 Since not all hosts will ever support HIP, ICMP 'Destination 1051 Protocol Unreachable' are to be expected and present a DOS attack. 1052 Against an initiator, the attack would look like the responder does 1053 not support HIP, but shortly after receiving the ICMP message, the 1054 initiator would receive a valid R1 HIP packet. Thus to protect 1055 against this attack, an initiator should not react to an ICMP 1056 message until a reasonable delta time to get the real responder's R1 1057 HIP packet. A similar attack against the responder is more 1058 involved. First an ICMP message is expected if the I1 was a DOS 1059 attack and the real owner of the spoofed IP address does not support 1060 HIP. The responder SHOULD NOT act on this ICMP message to remove 1061 the minimal state from the R1 HIP packet, but wait for either a 1062 valid I2 HIP packet or the natural timeout of the R1 HIP packet. 1063 This is to allow for a sophisticated attacker that is trying to 1064 break up the HIP exchange. Likewise, the initiator should ignore 1065 any ICMP message while waiting for an R2 HIP packet, deleting state 1066 only after a natural timeout. 1068 Another MIM attack is simulating a responder's rejection of a HIP 1069 initiation. This is a simple ICMP Host Unreachable, 1070 Administratively Prohibited message. A HIP packet was not used 1071 because it would either have to have unique content, and thus 1072 difficult to generate, resulting in yet another DOS attack, or just 1073 as spoofable as the ICMP message. The defense against this MIM 1074 attack is for the responder to wait a reasonable time period to get 1075 a valid R1 HIP packet. If one does not come, then the Initiator has 1076 to assume that the ICMP message is valid. Since this is the only 1077 point in the HIP exchange where this ICMP message is appropriate, it 1078 can be ignored at any other point in the exchange. 1080 10.1. Non-security Considerations 1082 The definition of the Host Identity states that the HI need not be a 1083 public key. That the HI could be any value; for example an FQDN. 1084 This document does not describe how to support a non-cryptographic 1085 HI. Such a HI would still offer the services of the ESEL for NAT 1086 traversal. It would carry the ESELs in an ESP that had neither 1087 privacy nor authentication (ESP EMPTY). Since this mode of HIP 1088 would offer so little additional functionality for so much addition 1089 to the IP kernel, it has not been defined in this document. Given 1091 Moskowitz 20 1092 Host Identity Payload Architecture December 1999 1094 how little public key cryptography HIP requires, HIP SHOULD only be 1095 implemented using public key Host Identities. 1097 11. IANA Considerations 1099 IANA has assigned Protocol number XX to HIP. 1101 A new KEY RR protocol of XX is assigned to HIP and an algorithm of 1102 XX is assigned to HIGH128. 1104 IANA will has also assigned new DNS OPT resource record OPTION-CODES 1105 of Remotes_HIGH [x], HIP_COOKIE [x], HIP_TRANSFORM [x], and 1106 Remotes_ESEL [x]. 1108 12. ICANN Considerations 1110 ICANN will need to set up the high.int zone and accredit the 1111 registered assigning authorities (RAA) for HAA field. With 21 bits, 1112 ICANN can allocate just over 2M registries. 1114 13. References 1116 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 1117 Requirement Levels", RFC 2119, Harvard University, March 1997 1119 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 1120 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 1121 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 1123 [DNSBIN], Crawford, M., "Binary Labels in the Domain Name System", 1124 RFC 2673, August 1999. 1126 [IKE], Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 1127 2409, November 1998. 1129 [ISAKMP], Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1130 "Internet Security Association and Key Management Protocol", RFC 1131 2408, November 1998. 1133 [DNS], Mockapetris, P., "Domain Names - Implementation And 1134 Specification", RFC 1035, November 1987. 1136 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 1137 RFC 2535, March 1999. 1139 [EDNS], Vixie, P., "Extension Mechanisms for DNS", RFC 2671, August 1140 1998. 1142 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 1143 Payload", RFC 2406, November 1998. 1145 Moskowitz 21 1146 Host Identity Payload Architecture December 1999 1148 14. Acknowledgments 1150 The drive to create HIP came to being after attending the MALLOC 1151 meeting at IETF 43. It has matured considerably since the early 1152 drafts thanks to extensive input from IETFers. Particular mention 1153 goes to the members of the NameSpace Research Group of the IRTF. 1154 Noel Chiappa provided the framework for ESELs and Kieth Moore the 1155 impetuous to provide resolvability. Steve Deering provided 1156 encouragement to keep working, as a solid proposal can act as a 1157 proof of ideas for a research group. Many others contributed; 1158 extensive security tips were provided by Steve Bellovin. Rob 1159 Austein kept the DNS parts on track. 1161 15. Author's Addresses 1163 Robert Moskowitz 1164 ICSA.net 1165 1200 Walnut Bottom Rd. 1166 Carlisle, PA 17013 1167 Email: rgm@icsa.net 1169 Moskowitz 22