idnits 2.17.1 draft-ietf-hip-dns-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 751. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 16, 2005) is 6706 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) -- Looks like a reference, but probably isn't: '1' on line 509 == Unused Reference: 'RFC3363' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-arch' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-mm' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 702, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. 'I-D.ietf-hip-rvs') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft Ericsson Research Nomadic Lab 4 Expires: June 19, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 December 16, 2005 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies a new resource record (RR) for the Domain 43 Name System (DNS), and how to use it with the Host Identity Protocol 44 (HIP.) This RR allows a HIP node to store in the DNS its Host 45 Identity (HI, the public component of the node public-private key 46 pair), Host Identity Tag (HIT, a truncated hash of its public key), 47 and the Domain Names of its rendezvous servers (RVS.) 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Simple static singly homed end-host . . . . . . . . . . . 6 55 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 7 56 3.3. Mixed Scenario . . . . . . . . . . . . . . . . . . . . . . 8 57 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 11 58 4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 11 59 4.2. Initiating connections based on DNS names . . . . . . . . 11 60 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 12 61 5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 12 62 5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 12 63 5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 13 64 5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.5. Public key format . . . . . . . . . . . . . . . . . . . . 13 66 5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 13 67 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 14 68 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 16 71 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 17 72 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 11.1. Normative references . . . . . . . . . . . . . . . . . . . 20 77 11.2. Informative references . . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 79 Intellectual Property and Copyright Statements . . . . . . . . . . 23 81 1. Introduction 83 This document specifies a new resource record (RR) for the Domain 84 Name System (DNS) [RFC1034], and how to use it with the Host Identity 85 Protocol (HIP) [I-D.ietf-hip-base]. This RR allows a HIP node to 86 store in the DNS its Host Identity (HI, the public component of the 87 node public-private key pair), Host Identity Tag (HIT, a truncated 88 hash of its HI), and the Domain Names of its rendezvous servers 89 (RVS.) [I-D.ietf-hip-rvs] 91 Currently, most of the Internet applications that need to communicate 92 with a remote host first translate a domain name (often obtained via 93 user input) into one or more IP address(es). This step occurs prior 94 to communication with the remote host, and relies on a DNS lookup. 96 With HIP, IP addresses are intended to be used mostly for on-the-wire 97 communication between end hosts, while most ULPs and applications use 98 HIs or HITs instead (ICMP might be an example of an ULP not using 99 them.) Consequently, we need a means to translate a domain name into 100 an HI. Using the DNS for this translation is pretty straightforward: 101 We define a new HIP resource record. Upon query by an application or 102 ULP for a FQDN -> IP lookup, the resolver would then additionally 103 perform an FQDN -> HI lookup, and use it to construct the resulting 104 HI -> IP mapping (which is internal to the HIP layer.) The HIP layer 105 uses the HI -> IP mapping to translate HIs and HITs into IP addresses 106 and vice versa. 108 The HIP rendezvous extensions [I-D.ietf-hip-rvs] proposal allows a 109 HIP node to be reached via the IP address(es) of a third party, the 110 node's rendezvous server (RVS.) An initiator willing to establish a 111 HIP association with a responder served by a RVS would typically 112 initiate a HIP exchange by sending an I1 towards the RVS IP address 113 rather than towards the responder IP address. Consequently, we need 114 a means to translate a domain name into the rendezvous server's 115 domain name. 117 This draft introduces the new HIP DNS Resource Record to store 118 Rendezvous Server (RVS), Host Identity (HI) and Host Identity Tag 119 (HIT) information. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC2119 [RFC2119]. 127 3. Usage Scenarios 129 In this section, we briefly introduce a number of usage scenarios 130 where the DNS is useful with the Host Identity Protocol. 132 With HIP, most application and ULPs are unaware of the IP addresses 133 used to carry packets on the wire. Consequently, a HIP node could 134 take advantage of having multiple IP addresses for fail-over, 135 redundancy, mobility, or renumbering, in a manner which is 136 transparent to most ULPs and applications (because they are bound to 137 HIs, hence they are agnostic to these IP address changes.) 139 In these situations, a node wishing to be reachable by reference to 140 its FQDN should store the following information in the DNS: 142 o A set of IP address(es) through A and AAAA RRs. 144 o A Host Identity (HI), Host Identity Tag (HIT) and possibly a set 145 of rendezvous server(s) (RVS) through HIP RRs. 147 When a HIP node wants to initiate a communication with another HIP 148 node, it first needs to perform a HIP base exchange to set-up a HIP 149 association towards its peer. Although such an exchange can be 150 initiated opportunistically, i.e., without prior knowledge of the 151 responder's HI, by doing so both nodes knowingly risk man-in-the- 152 middle attacks on the HIP exchange. To prevent these attacks, it is 153 recommended that the initiator first obtain the HI of the responder, 154 and then initiate the exchange. This can be done, for example, 155 through manual configuration or DNS lookups. Hence, a new HIP RR is 156 introduced. 158 When a HIP node is frequently changing its IP address(es), the 159 dynamic DNS update latency may prevent it from publishing its new IP 160 address(es) in the DNS. For solving this problem, the HIP 161 architecture introduces rendezvous servers (RVS.) A HIP host uses a 162 rendezvous server as a rendezvous point, to maintain reachability 163 with possible HIP initiators. Such a HIP node would publish in the 164 DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to- 165 date with its current set of IP addresses. 167 When a HIP node wants to initiate a HIP exchange with a responder it 168 will perform a number of DNS lookups. Depending on the type of the 169 implementation, the order in which those lookups will be issued may 170 vary. For instance, implementations using IP address in APIs may 171 typically first query for A and/or AAAA records at the responder 172 FQDN, while those using HIT in APIS may typically first query for HIP 173 RRs. 175 In the following we assume that the initiator first queries for A 176 and/or AAAA records at the responder FQDN. 178 If the query for the A and/or AAAA was responded to with a DNS answer 179 with RCODE=3 (Name Error), then the responder's information is not 180 present in the DNS and further queries SHOULD NOT be made. 182 In case the query for the address records returned a DNS answer with 183 RCODE=0 (No Error), then the initiator sends out one more query for 184 for the HIP type at the responder's FQDN. 186 Depending on the combinations of answer the situations described in 187 Section 3.1, Section 3.2 and Section 3.3 can occur. 189 Note that storing HIP RR information in the DNS at a FQDN which is 190 assigned to a non-HIP node might have ill effects on its reachability 191 by HIP nodes. 193 3.1. Simple static singly homed end-host 195 A HIP node (R) with a single static network attachment, wishing to be 196 reachable by reference to its FQDN (www.example.com), would store in 197 the DNS, in addition to its IP address(es) (IP-R), its Host Identity 198 (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record. 200 An initiator willing to associate with a node would typically issue 201 the following queries: 203 QNAME=www.example.com, QTYPE=A 205 (QCLASS=IN is assumed and omitted from the examples) 207 Which returns a DNS packet with RCODE=0 and one or more A RRs A with 208 the address of the responder (e.g. IP-R) in the answer section. 210 QNAME=www.example.com, QTYPE=HIP 212 Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 213 the HIT and HI (e.g. HIT-R and HI-R) of the responder in the answer 214 section, but no RVS. 216 Caption: In the remainder of this document, for the sake of keeping 217 diagrams simple and concise, several DNS queries and answers 218 are represented as one single transaction, while in fact 219 there are several queries and answers flowing back and 220 forth, as described in the textual examples. 222 [A? HIP? ] 223 [www.example.com] +-----+ 224 +-------------------------------->| | 225 | | DNS | 226 | +-------------------------------| | 227 | | [A? HIP? ] +-----+ 228 | | [www.example.com] 229 | | [A IP-R ] 230 | | [HIP HIT-R HI-R ] 231 | v 232 +-----+ +-----+ 233 | |--------------I1------------->| | 234 | I |<-------------R1--------------| R | 235 | |--------------I2------------->| | 236 | |<-------------R2--------------| | 237 +-----+ +-----+ 239 The initiator would then send an I1 to the responder's IP addresses 240 (IP-R.) 242 3.2. Mobile end-host 244 A mobile HIP node (R) wishing to be reachable by reference to its 245 FQDN (www.example.com) would store in the DNS, possibly in addition 246 to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R) and the 247 domain name(s) of its rendezvous server(s) (rvs.example.com) in HIP 248 resource record(s). The mobile HIP node also needs to notify its 249 rendezvous servers of any change in its set of IP address(es). 251 An initiator willing to associate with such mobile node would 252 typically issue the following queries: 254 QNAME=www.example.com, QTYPE=A 256 Which returns a DNS packet with RCODE=0 and an empty answer section. 258 QNAME=www.example.com, QTYPE=HIP 260 Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 261 the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and 262 rvs.example.com) of the responder in the answer section. 264 QNAME=rvs.example.com, QTYPE=A 266 [A? HIP? ] 267 [www.example.com] 269 [A? ] 270 [RVS.example.com] +-----+ 271 +----------------------------------------->| | 272 | | DNS | 273 | +----------------------------------------| | 274 | | [A? HIP? ] +-----+ 275 | | [www.example.com ] 276 | | [HIP HIT-R HI-R rvs.example.com] 277 | | 278 | | [A? ] 279 | | [rvs.example.com] 280 | | [A IP-RVS ] 281 | | 282 | | +-----+ 283 | | +------I1----->| RVS |-----I1------+ 284 | | | +-----+ | 285 | | | | 286 | | | | 287 | v | v 288 +-----+ +-----+ 289 | |<---------------R1------------| | 290 | I |----------------I2----------->| R | 291 | |<---------------R2------------| | 292 +-----+ +-----+ 294 The initiator would then send an I1 to the RVS IP address (IP-RVS.) 295 Following, the RVS will relay the I1 up to the mobile node's IP 296 address (IP-R), which will complete the HIP exchange. 298 3.3. Mixed Scenario 300 A HIP node might be configured with more than one IP address (multi- 301 homed), or rendezvous server (multi-reachable.) In these cases, it 302 is possible that the DNS returns multiple A or AAAA RRs, as well as 303 HIP RRs containing one or multiple rendezvous servers. In addition 304 to its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host 305 would store in the DNS its HI (HI-R), HIT (HIT-R) and domain name(s) 306 of its RVS(s) (rvs.example.com) in HIP RRs. 308 An initiator willing to associate with such mobile node would 309 typically issue the following queries: 311 QNAME=www.example.com, QTYPE=A 313 Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs 314 containing IP address(es) (e.g. IP-R1 and IP-R2) in the answer 315 section. 317 QNAME=www.example.com, QTYPE=HIP 319 Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 320 the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and 321 rvs.example.com) of the responder in the answer section. 323 QNAME=rvs.example.com, QTYPE=A 325 [A? HIP? ] 326 [www.example.com] 328 [A? ] 329 [RVS.example.com] +-----+ 330 +----------------------------------------->| | 331 | | DNS | 332 | +----------------------------------------| | 333 | | [A? HIP? ] +-----+ 334 | | [www.example.com ] 335 | | [A IP-R ] 336 | | [HIP HIT-R HI-R rvs.example.com] 337 | | 338 | | [A? ] 339 | | [rvs.example.com] 340 | | [A IP-RVS ] 341 | | 342 | | +-----+ 343 | | +------I1----->| RVS |-----I1------+ 344 | | | +-----+ | 345 | | | | 346 | | | | 347 | v | v 348 +-----+ +-----+ 349 | |----------------I1----------->| | 350 | |<---------------R1------------| | 351 | I |----------------I2----------->| R | 352 | |<---------------R2------------| | 353 +-----+ +-----+ 355 The initiator would then typically send the same I1 to both the RVS 356 and the responder's IP addresses (IP-RVS and IP-R.) 358 4. Overview of using the DNS with HIP 360 4.1. Storing HI, HIT and RVS in DNS 362 Any conforming implementation may store a Host Identity (HI) and its 363 associated Host Identity Tag (HIT) in a DNS HIP RDATA format. If a 364 particular form of an HI does not already have a specified RDATA 365 format, a new RDATA-like format SHOULD be defined for the HI. HI and 366 HIT are defined in Section 3 of [I-D.ietf-hip-base]. 368 Upon return of a HIP RR, a host MUST always calculate the HI- 369 derivative HIT to be used in the HIP exchange, as specified in 370 Section 3 of the HIP base specification [I-D.ietf-hip-base], while 371 the HIT possibly embedded along SHOULD only be used as an 372 optimization (e.g. table lookup.) 374 The HIP resource record may also contains one or more domain name(s) 375 of rendezvous server(s) towards which HIP I1 packets might be sent to 376 trigger the establishment of an association with the entity named by 377 this resource record [I-D.ietf-hip-rvs]. 379 An RVS receiving such an I1 would then relay it to the appropriate 380 responder (the owner of the I1 receiver HIT.) The responder will 381 then complete the exchange with the initiator, typically without 382 ongoing help from the RVS. 384 4.2. Initiating connections based on DNS names 386 On a HIP node, a Host Identity Protocol exchange SHOULD be initiated 387 whenever an Upper Layer Protocol attempt to communicate with an 388 entity and the DNS lookup returns HIP resource records. 390 5. HIP RR Storage Format 392 The RDATA for a HIP RR consists of a public key algorithm type, the 393 HIT length, a HIT, a public key, and optionnally one or more 394 rendezvous server(s). 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | HIT length | PK algorithm | PK length | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 401 | | 402 ~ HIT ~ 403 | | 404 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | | 406 +-+-+-+-+-+-+-+-+-+-+-+ + 407 | Public Key | 408 ~ ~ 409 | | 410 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 413 | | 414 ~ Rendezvous Servers ~ 415 | | 416 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 +-+-+-+-+-+-+-+ 420 The HIT length, PK algorithm, PK length, HIT and Public Key field are 421 REQUIRED. The Rendezvous Servers field is OPTIONAL. 423 5.1. HIT length format 425 The HIT length indicates the length in bytes of the HIT field. 427 5.2. PK algorithm format 429 The PK algorithm field indicates the public key cryptographic 430 algorithm and the implied public key field format. This document 431 reuses the values defined for the 'algorithm type' of the IPSECKEY RR 432 [RFC4025] 'gateway type' field. 434 The presently defined values are shown here for reference: 436 1 A DSA key is present, in the format defined in RFC2536 437 [RFC2536]. 439 2 A RSA key is present, in the format defined in RFC3110 440 [RFC3110]. 442 5.3. PK length format 444 The PK length indicates the length in bytes of the Public key field. 446 5.4. HIT format 448 The HIT is stored, as a binary value, in network byte order. 450 5.5. Public key format 452 Both of the public key types defined in this document (RSA and DSA) 453 reuse the public key formats defined for the IPSECKEY RR [RFC4025] 454 (which in turns contains the algorithm-specific portion of the KEY RR 455 RDATA, all of the KEY RR DATA after the first four octets, 456 corresponding to the same portion of the KEY RR that must be 457 specified by documents that define a DNSSEC algorithm.) 459 In the future, if a new algorithm is to be used both by IPSECKEY RR 460 and HIP RR, it should use the same public key encoding for both RRs. 461 Unless specified otherwise, the HIP RR public key field SHOULD use 462 the same public key format as the IPSECKEY RR RDATA for the 463 corresponding algorithm. 465 The DSA key format is defined in RFC2536 [RFC2536]. 467 The RSA key format is defined in RFC3110 [RFC3110] and the RSA key 468 size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] 469 specification. 471 5.6. Rendezvous servers format 473 The Rendezvous servers field indicates one or more variable length 474 wire-encoded domain names rendezvous server(s), as described in 475 Section 3.3 of RFC1035 [RFC1035]. The wire-encoded format is self- 476 describing, so the length is implicit. The domain names MUST NOT be 477 compressed. The rendezvous server(s) are listed in order of 478 preference (i.e. first rendezvous server(s) are preferred). 480 6. HIP RR Presentation Format 482 This section specifies the representation of the HIP RR in a zone 483 data master file. 485 The HIT length field is not represented as it is implicitly known 486 thanks to the HIT field representation. 488 The PK algorithm field is represented as unsigned integers. 490 The PK length field is not represented as it is implicitly known 491 thanks to the Public key field representation. 493 The HIT field is represented as the Base16 encoding [RFC3548] (a.k.a. 494 hex or hexadecimal) of the HIT. The encoding MUST NOT contain 495 whitespace(s). 497 The Public Key field is represented as the Base64 encoding [RFC3548] 498 of the public key. The encoding MAY contain whitespace(s), and such 499 whitespace(s) MUST be ignored. 501 The Rendezvous servers field is represented by one or more 502 uncompressed domain name(s) 504 The complete representation of the HPIHI record is: 506 IN HIP ( pk-algorithm 507 base16-encoded-hit 508 base64-encoded-public-key 509 rendezvous-server[1] 510 ... 511 rendezvous-server[n] ) 513 7. Examples 515 Example of a node with HI and HIT but no RVS: 517 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 518 AB3NzaC1kc3MAAACBAOBhKn 519 TCPOuFBzZQX/N3O9dm9P9iv 520 UIMoId== ) 522 Example of a node with a HI, HIT and one RVS: 524 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 525 AB3NzaC1kc3MAAACBAOBhKn 526 TCPOuFBzZQX/N3O9dm9P9iv 527 UIMoId== 528 rvs.example.com ) 530 Example of a node with a HI, HIT and two RVS: 532 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 533 AB3NzaC1kc3MAAACBAOBhKn 534 TCPOuFBzZQX/N3O9dm9P9iv 535 UIMoId== 536 rvs1.example.com 537 rvs2.example.com ) 539 8. Security Considerations 541 Though the security considerations of the HIP DNS extensions still 542 need to be more investigated and documented, this section contains a 543 description of the known threats involved with the usage of the HIP 544 DNS extensions. 546 In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS 547 Extensions allows to provision two HIP nodes with the public keying 548 material (HI) of their peer. These HIs will be subsequently used in 549 a key exchange between the peers. Hence, the HIP DNS Extensions 550 introduce the same kind of threats that IPSECKEY does, plus threats 551 caused by the possibility given to a HIP node to initiate or accept a 552 HIP exchange using "opportunistic" or "unpublished initiator HI" 553 modes. 555 A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure 556 channel insuring proper data integrity of the RRs. DNSSEC [RFC2065] 557 provides such a secure channel. 559 In the absence of a proper secure channel, both parties are 560 vulnerable to MitM and DoS attacks, and unrelated parties might be 561 subject to DoS attacks as well. These threats are described in the 562 following sections. 564 8.1. Attacker tampering with an insecure HIP RR 566 The HIP RR contains public keying material in the form of the named 567 peer's public key (the HI) and its secure hash (the HIT.) Both of 568 these are not sensitive to attacks where an adversary gains knowledge 569 of them. However, an attacker that is able to mount an active attack 570 on the DNS, i.e., tampers with this HIP RR (e.g. using DNS spoofing) 571 is able to mount Man-in-the-Middle attacks on the cryptographic core 572 of the eventual HIP exchange (responder's HIP RR rewritten by the 573 attacker.) 575 The HIP RR may contain a rendezvous server domain name resolved into 576 a destination IP address where the named peer is reachable by an I1 577 (HIP Rendezvous Extensions IPSECKEY RR [I-D.ietf-hip-rvs].) Thus, an 578 attacker able to tamper with this RR is able to redirect I1 packets 579 sent to the named peer to a chosen IP address, for DoS or MitM 580 attacks. Note that this kind of attack is not specific to HIP and 581 exists independently to whether or not HIP and the HIP RR are used. 582 Such an attacker might tamper with A and AAAA RRs as well. 584 An attacker might obviously use these two attacks in conjunction: It 585 will replace the responder's HI and RVS IP address by its owns in a 586 spoofed DNS packet sent to the initiator HI, then redirect all 587 exchanged packets to him and mount a MitM on HIP. In this case HIP 588 won't provide confidentiality nor initiator HI protection from 589 eavesdroppers. 591 8.2. Hash and HITs Collisions 593 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 594 by HIP to generate a HIT from an HI) eventually become insecure, 595 because an exploit has been found in which an attacker with a 596 reasonable computation power breaks one of the security features of 597 the hash (e.g. its supposed collision resistance.) This is why a HIP 598 end-node implementation SHOULD NOT authenticate its HIP peers based 599 solely on a HIT retrieved from DNS, but SHOULD rather use HI-based 600 authentication. 602 8.3. DNSSEC 604 In the absence of DNSSEC, the HIP RR is subject to the threats 605 described in RFC 3833 [RFC3833]. 607 9. IANA Considerations 609 IANA should allocate one new RR type code for the HIP RR from the 610 standard RR type space. 612 IANA does not need to open a new registry for public key algorithms 613 of the HIP RR because the HIP RR reuses "algorithms types" defined 614 for the IPSECKEY RR [RFC4025]. The presently defined values are 615 shown here for reference: 617 0 is reserved 619 1 is RSA 621 2 is DSA 623 10. Acknowledgments 625 As usual in the IETF, this document is the result of a collaboration 626 between many people. The authors would like to thanks the author 627 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 628 [RFC4025] specification, which this document was framed after. The 629 authors would also like to thanks the following people, who have 630 provided thoughtful and helpful discussions and/or suggestions, that 631 have helped improving this document: Rob Austein, Hannu Flinck, Tom 632 Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, 633 and Gabriel Montenegro. Some parts of this draft stem from 634 [I-D.ietf-hip-base]. 636 Julien Laganier is partly funded by Ambient Networks, a research 637 project supported by the European Commission under its Sixth 638 Framework Program. The views and conclusions contained herein are 639 those of the authors and should not be interpreted as necessarily 640 representing the official policies or endorsements, either expressed 641 or implied, of the Ambient Networks project or the European 642 Commission. 644 11. References 646 11.1. Normative references 648 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 649 STD 13, RFC 1034, November 1987. 651 [RFC1035] Mockapetris, P., "Domain names - implementation and 652 specification", STD 13, RFC 1035, November 1987. 654 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 655 Extensions", RFC 2065, January 1997. 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 661 (DNS)", RFC 2536, March 1999. 663 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 664 Name System (DNS)", RFC 3110, May 2001. 666 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 667 Hain, "Representing Internet Protocol version 6 (IPv6) 668 Addresses in the Domain Name System (DNS)", RFC 3363, 669 August 2002. 671 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 672 Encodings", RFC 3548, July 2003. 674 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 675 "DNS Extensions to Support IP Version 6", RFC 3596, 676 October 2003. 678 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 679 Material in DNS", RFC 4025, March 2005. 681 [I-D.ietf-hip-base] 682 Moskowitz, R., "Host Identity Protocol", 683 draft-ietf-hip-base-04 (work in progress), October 2005. 685 [I-D.ietf-hip-rvs] 686 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 687 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 688 progress), October 2005. 690 11.2. Informative references 692 [I-D.ietf-hip-arch] 693 Moskowitz, R. and P. Nikander, "Host Identity Protocol 694 Architecture", draft-ietf-hip-arch-03 (work in progress), 695 August 2005. 697 [I-D.ietf-hip-mm] 698 Nikander, P., "End-Host Mobility and Multihoming with the 699 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 700 progress), July 2005. 702 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 703 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 704 October 1998. 706 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 707 Name System (DNS)", RFC 3833, August 2004. 709 Authors' Addresses 711 Pekka Nikander 712 Ericsson Research Nomadic Lab 713 JORVAS FIN-02420 714 FINLAND 716 Phone: +358 9 299 1 717 Email: pekka.nikander@nomadiclab.com 719 Julien Laganier 720 DoCoMo Communications Laboratories Europe GmbH 721 Landsberger Strasse 312 722 Munich 80687 723 Germany 725 Phone: +49 89 56824 231 726 Email: julien.ietf@laposte.net 727 URI: http://www.docomolab-euro.com/ 729 Intellectual Property Statement 731 The IETF takes no position regarding the validity or scope of any 732 Intellectual Property Rights or other rights that might be claimed to 733 pertain to the implementation or use of the technology described in 734 this document or the extent to which any license under such rights 735 might or might not be available; nor does it represent that it has 736 made any independent effort to identify any such rights. Information 737 on the procedures with respect to rights in RFC documents can be 738 found in BCP 78 and BCP 79. 740 Copies of IPR disclosures made to the IETF Secretariat and any 741 assurances of licenses to be made available, or the result of an 742 attempt made to obtain a general license or permission for the use of 743 such proprietary rights by implementers or users of this 744 specification can be obtained from the IETF on-line IPR repository at 745 http://www.ietf.org/ipr. 747 The IETF invites any interested party to bring to its attention any 748 copyrights, patents or patent applications, or other proprietary 749 rights that may cover technology that may be required to implement 750 this standard. Please address the information to the IETF at 751 ietf-ipr@ietf.org. 753 Disclaimer of Validity 755 This document and the information contained herein are provided on an 756 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 758 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 759 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 760 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 Copyright Statement 765 Copyright (C) The Internet Society (2005). This document is subject 766 to the rights, licenses and restrictions contained in BCP 78, and 767 except as set forth therein, the authors retain all their rights. 769 Acknowledgment 771 Funding for the RFC Editor function is currently provided by the 772 Internet Society.