idnits 2.17.1 draft-ietf-hip-dns-05.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 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 706. ** 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 (February 16, 2006) is 6616 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 464 == Unused Reference: 'RFC3363' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-arch' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-mm' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 657, 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: August 20, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 February 16, 2006 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-05 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 August 20, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 9 57 4.1. Storing HI, HIT and RVS in DNS . . . . . . . . . . . . . . 9 58 4.2. Initiating connections based on DNS names . . . . . . . . 9 59 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 10 60 5.1. HIT length format . . . . . . . . . . . . . . . . . . . . 10 61 5.2. PK algorithm format . . . . . . . . . . . . . . . . . . . 10 62 5.3. PK length format . . . . . . . . . . . . . . . . . . . . . 11 63 5.4. HIT format . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.5. Public key format . . . . . . . . . . . . . . . . . . . . 11 65 5.6. Rendezvous servers format . . . . . . . . . . . . . . . . 11 66 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 12 67 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 8.1. Attacker tampering with an insecure HIP RR . . . . . . . . 14 70 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 15 71 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 11.1. Normative references . . . . . . . . . . . . . . . . . . . 18 76 11.2. Informative references . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 78 Intellectual Property and Copyright Statements . . . . . . . . . . 21 80 1. Introduction 82 This document specifies a new resource record (RR) for the Domain 83 Name System (DNS) [RFC1034], and how to use it with the Host Identity 84 Protocol (HIP) [I-D.ietf-hip-base]. This RR allows a HIP node to 85 store in the DNS its Host Identity (HI, the public component of the 86 node public-private key pair), Host Identity Tag (HIT, a truncated 87 hash of its HI), and the Domain Names of its rendezvous servers 88 (RVS.) [I-D.ietf-hip-rvs] 90 Currently, most of the Internet applications that need to communicate 91 with a remote host first translate a domain name (often obtained via 92 user input) into one or more IP address(es). This step occurs prior 93 to communication with the remote host, and relies on a DNS lookup. 95 With HIP, IP addresses are intended to be used mostly for on-the-wire 96 communication between end hosts, while most ULPs and applications use 97 HIs or HITs instead (ICMP might be an example of an ULP not using 98 them.) Consequently, we need a means to translate a domain name into 99 an HI. Using the DNS for this translation is pretty straightforward: 100 We define a new HIP resource record. Upon query by an application or 101 ULP for a FQDN -> IP lookup, the resolver would then additionally 102 perform an FQDN -> HI lookup, and use it to construct the resulting 103 HI -> IP mapping (which is internal to the HIP layer.) The HIP layer 104 uses the HI -> IP mapping to translate HIs and HITs into IP addresses 105 and vice versa. 107 The HIP rendezvous extensions [I-D.ietf-hip-rvs] proposal allows a 108 HIP node to be reached via the IP address(es) of a third party, the 109 node's rendezvous server (RVS.) An initiator willing to establish a 110 HIP association with a responder served by a RVS would typically 111 initiate a HIP exchange by sending an I1 towards the RVS IP address 112 rather than towards the responder IP address. Consequently, we need 113 a means to translate a domain name into the rendezvous server's 114 domain name. 116 This draft introduces the new HIP DNS Resource Record to store 117 Rendezvous Server (RVS), Host Identity (HI) and Host Identity Tag 118 (HIT) information. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC2119 [RFC2119]. 126 3. Usage Scenarios 128 In this section, we briefly introduce a number of usage scenarios 129 where the DNS is useful with the Host Identity Protocol. 131 With HIP, most application and ULPs are unaware of the IP addresses 132 used to carry packets on the wire. Consequently, a HIP node could 133 take advantage of having multiple IP addresses for fail-over, 134 redundancy, mobility, or renumbering, in a manner which is 135 transparent to most ULPs and applications (because they are bound to 136 HIs, hence they are agnostic to these IP address changes.) 138 In these situations, a node wishing to be reachable by reference to 139 its FQDN should store the following information in the DNS: 141 o A set of IP address(es) through A and AAAA RRs. 143 o A Host Identity (HI), Host Identity Tag (HIT) and possibly a set 144 of rendezvous server(s) (RVS) through HIP RRs. 146 When a HIP node wants to initiate a communication with another HIP 147 node, it first needs to perform a HIP base exchange to set-up a HIP 148 association towards its peer. Although such an exchange can be 149 initiated opportunistically, i.e., without prior knowledge of the 150 responder's HI, by doing so both nodes knowingly risk man-in-the- 151 middle attacks on the HIP exchange. To prevent these attacks, it is 152 recommended that the initiator first obtain the HI of the responder, 153 and then initiate the exchange. This can be done, for example, 154 through manual configuration or DNS lookups. Hence, a new HIP RR is 155 introduced. 157 When a HIP node is frequently changing its IP address(es), the 158 dynamic DNS update latency may prevent it from publishing its new IP 159 address(es) in the DNS. For solving this problem, the HIP 160 architecture introduces rendezvous servers (RVS.) A HIP host uses a 161 rendezvous server as a rendezvous point, to maintain reachability 162 with possible HIP initiators. Such a HIP node would publish in the 163 DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-to- 164 date with its current set of IP addresses. 166 When a HIP node wants to initiate a HIP exchange with a responder it 167 will perform a number of DNS lookups. Depending on the type of the 168 implementation, the order in which those lookups will be issued may 169 vary. For instance, implementations using HIT in APIS may typically 170 first query for HIP resource records at the responder FQDN, while 171 those using IP address in APIs may typically first query for A and/or 172 AAAA resource records. 174 In the following we assume that the initiator first queries for HIP 175 resource records at the responder FQDN. 177 If the query for the HIP type was responded to with a DNS answer with 178 RCODE=3 (Name Error), then the responder's information is not present 179 in the DNS and further queries SHOULD NOT be made. 181 In case the query for the HIP records returned a DNS answer with 182 RCODE=0 (No Error), then the initiator sends out one more query for 183 for A and AAAA types at the responder's FQDN. 185 Depending on the combinations of answer the situations described in 186 Section 3.1 and Section 3.2 can occur. 188 Note that storing HIP RR information in the DNS at a FQDN which is 189 assigned to a non-HIP node might have ill effects on its reachability 190 by HIP nodes. 192 3.1. Simple static singly homed end-host 194 A HIP node (R) with a single static network attachment, wishing to be 195 reachable by reference to its FQDN (www.example.com), would store in 196 the DNS, in addition to its IP address(es) (IP-R), its Host Identity 197 (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record. 199 An initiator willing to associate with a node would typically issue 200 the following queries: 202 QNAME=www.example.com, QTYPE=HIP 204 (QCLASS=IN is assumed and omitted from the examples) 206 Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 207 the HIT and HI (e.g. HIT-R and HI-R) of the responder in the answer 208 section, but no RVS. 210 QNAME=www.example.com, QTYPE=A 212 Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs 213 containing IP address(es) of the responder (e.g. IP-R) in the answer 214 section. 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 [HIP? A? ] 223 [www.example.com] +-----+ 224 +-------------------------------->| | 225 | | DNS | 226 | +-------------------------------| | 227 | | [HIP? A? ] +-----+ 228 | | [www.example.com] 229 | | [HIP HIT-R HI-R ] 230 | | [A IP-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=HIP 256 Which returns a DNS packet with RCODE=0 and one or more HIP RRs with 257 the HIT, HI and RVS domain name(s) (e.g. HIT-R, HI-R, and 258 rvs.example.com) of the responder in the answer section. 260 QNAME=rvs.example.com, QTYPE=A 262 Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs 263 containing IP address(es) of the responder's RVS (e.g. IP-RVS) in 264 the answer section. 266 [HIP? ] 267 [www.example.com] 269 [A? ] 270 [rvs.example.com] +-----+ 271 +----------------------------------------->| | 272 | | DNS | 273 | +----------------------------------------| | 274 | | [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 4. Overview of using the DNS with HIP 300 4.1. Storing HI, HIT and RVS in DNS 302 Any conforming implementation may store a Host Identity (HI) and its 303 associated Host Identity Tag (HIT) in a DNS HIP RDATA format. If a 304 particular form of an HI does not already have a specified RDATA 305 format, a new RDATA-like format SHOULD be defined for the HI. HI and 306 HIT are defined in Section 3 of [I-D.ietf-hip-base]. 308 Upon return of a HIP RR, a host MUST always calculate the HI- 309 derivative HIT to be used in the HIP exchange, as specified in 310 Section 3 of the HIP base specification [I-D.ietf-hip-base], while 311 the HIT possibly embedded along SHOULD only be used as an 312 optimization (e.g. table lookup.) 314 The HIP resource record may also contains one or more domain name(s) 315 of rendezvous server(s) towards which HIP I1 packets might be sent to 316 trigger the establishment of an association with the entity named by 317 this resource record [I-D.ietf-hip-rvs]. 319 The rendezvous server field of the HIP resource record stored at a 320 given domain name MAY include the domain name itself. A semantically 321 equivalent situation occurs if no rendezvous server is stored in the 322 HIP resource record of that domain. Such situations occurs in two 323 cases: 325 o The host is mobile, and the A and/or AAAA resource record(s) 326 stored at its domain name contains the IP address(es) of its 327 rendezvous server rather than its own one. 329 o The host is stationary, and can be reached directly at IP 330 address(es) contained in A and/or AAAA resource record(s) stored 331 at its domain name. This a degenerated case of rendezvous service 332 where the host somewhat acts as a rendezvous server for itself. 334 An RVS receiving such an I1 would then relay it to the appropriate 335 responder (the owner of the I1 receiver HIT.) The responder will 336 then complete the exchange with the initiator, typically without 337 ongoing help from the RVS. 339 4.2. Initiating connections based on DNS names 341 On a HIP node, a Host Identity Protocol exchange SHOULD be initiated 342 whenever an Upper Layer Protocol attempt to communicate with an 343 entity and the DNS lookup returns HIP resource records. 345 5. HIP RR Storage Format 347 The RDATA for a HIP RR consists of a public key algorithm type, the 348 HIT length, a HIT, a public key, and optionnally one or more 349 rendezvous server(s). 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | HIT length | PK algorithm | PK length | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 356 | | 357 ~ HIT ~ 358 | | 359 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | | 361 +-+-+-+-+-+-+-+-+-+-+-+ + 362 | Public Key | 363 ~ ~ 364 | | 365 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 368 | | 369 ~ Rendezvous Servers ~ 370 | | 371 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 +-+-+-+-+-+-+-+ 375 The HIT length, PK algorithm, PK length, HIT and Public Key field are 376 REQUIRED. The Rendezvous Servers field is OPTIONAL. 378 5.1. HIT length format 380 The HIT length indicates the length in bytes of the HIT field. 382 5.2. PK algorithm format 384 The PK algorithm field indicates the public key cryptographic 385 algorithm and the implied public key field format. This document 386 reuses the values defined for the 'algorithm type' of the IPSECKEY RR 387 [RFC4025] 'gateway type' field. 389 The presently defined values are shown here for reference: 391 1 A DSA key is present, in the format defined in RFC2536 392 [RFC2536]. 394 2 A RSA key is present, in the format defined in RFC3110 395 [RFC3110]. 397 5.3. PK length format 399 The PK length indicates the length in bytes of the Public key field. 401 5.4. HIT format 403 The HIT is stored, as a binary value, in network byte order. 405 5.5. Public key format 407 Both of the public key types defined in this document (RSA and DSA) 408 reuse the public key formats defined for the IPSECKEY RR [RFC4025] 409 (which in turns contains the algorithm-specific portion of the KEY RR 410 RDATA, all of the KEY RR DATA after the first four octets, 411 corresponding to the same portion of the KEY RR that must be 412 specified by documents that define a DNSSEC algorithm.) 414 In the future, if a new algorithm is to be used both by IPSECKEY RR 415 and HIP RR, it should use the same public key encoding for both RRs. 416 Unless specified otherwise, the HIP RR public key field SHOULD use 417 the same public key format as the IPSECKEY RR RDATA for the 418 corresponding algorithm. 420 The DSA key format is defined in RFC2536 [RFC2536]. 422 The RSA key format is defined in RFC3110 [RFC3110] and the RSA key 423 size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] 424 specification. 426 5.6. Rendezvous servers format 428 The Rendezvous servers field indicates one or more variable length 429 wire-encoded domain names rendezvous server(s), as described in 430 Section 3.3 of RFC1035 [RFC1035]. The wire-encoded format is self- 431 describing, so the length is implicit. The domain names MUST NOT be 432 compressed. The rendezvous server(s) are listed in order of 433 preference (i.e. first rendezvous server(s) are preferred). 435 6. HIP RR Presentation Format 437 This section specifies the representation of the HIP RR in a zone 438 data master file. 440 The HIT length field is not represented as it is implicitly known 441 thanks to the HIT field representation. 443 The PK algorithm field is represented as unsigned integers. 445 The PK length field is not represented as it is implicitly known 446 thanks to the Public key field representation. 448 The HIT field is represented as the Base16 encoding [RFC3548] (a.k.a. 449 hex or hexadecimal) of the HIT. The encoding MUST NOT contain 450 whitespace(s). 452 The Public Key field is represented as the Base64 encoding [RFC3548] 453 of the public key. The encoding MAY contain whitespace(s), and such 454 whitespace(s) MUST be ignored. 456 The Rendezvous servers field is represented by one or more 457 uncompressed domain name(s) 459 The complete representation of the HPIHI record is: 461 IN HIP ( pk-algorithm 462 base16-encoded-hit 463 base64-encoded-public-key 464 rendezvous-server[1] 465 ... 466 rendezvous-server[n] ) 468 7. Examples 470 Example of a node with HI and HIT but no RVS: 472 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 473 AB3NzaC1kc3MAAACBAOBhKn 474 TCPOuFBzZQX/N3O9dm9P9iv 475 UIMoId== ) 477 Example of a node with a HI, HIT and one RVS: 479 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 480 AB3NzaC1kc3MAAACBAOBhKn 481 TCPOuFBzZQX/N3O9dm9P9iv 482 UIMoId== 483 rvs.example.com ) 485 Example of a node with a HI, HIT and two RVS: 487 www.example.com IN HIP ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 488 AB3NzaC1kc3MAAACBAOBhKn 489 TCPOuFBzZQX/N3O9dm9P9iv 490 UIMoId== 491 rvs1.example.com 492 rvs2.example.com ) 494 8. Security Considerations 496 Though the security considerations of the HIP DNS extensions still 497 need to be more investigated and documented, this section contains a 498 description of the known threats involved with the usage of the HIP 499 DNS extensions. 501 In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS 502 Extensions allows to provision two HIP nodes with the public keying 503 material (HI) of their peer. These HIs will be subsequently used in 504 a key exchange between the peers. Hence, the HIP DNS Extensions 505 introduce the same kind of threats that IPSECKEY does, plus threats 506 caused by the possibility given to a HIP node to initiate or accept a 507 HIP exchange using "opportunistic" or "unpublished initiator HI" 508 modes. 510 A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure 511 channel insuring proper data integrity of the RRs. DNSSEC [RFC2065] 512 provides such a secure channel. 514 In the absence of a proper secure channel, both parties are 515 vulnerable to MitM and DoS attacks, and unrelated parties might be 516 subject to DoS attacks as well. These threats are described in the 517 following sections. 519 8.1. Attacker tampering with an insecure HIP RR 521 The HIP RR contains public keying material in the form of the named 522 peer's public key (the HI) and its secure hash (the HIT.) Both of 523 these are not sensitive to attacks where an adversary gains knowledge 524 of them. However, an attacker that is able to mount an active attack 525 on the DNS, i.e., tampers with this HIP RR (e.g. using DNS spoofing) 526 is able to mount Man-in-the-Middle attacks on the cryptographic core 527 of the eventual HIP exchange (responder's HIP RR rewritten by the 528 attacker.) 530 The HIP RR may contain a rendezvous server domain name resolved into 531 a destination IP address where the named peer is reachable by an I1 532 (HIP Rendezvous Extensions IPSECKEY RR [I-D.ietf-hip-rvs].) Thus, an 533 attacker able to tamper with this RR is able to redirect I1 packets 534 sent to the named peer to a chosen IP address, for DoS or MitM 535 attacks. Note that this kind of attack is not specific to HIP and 536 exists independently to whether or not HIP and the HIP RR are used. 537 Such an attacker might tamper with A and AAAA RRs as well. 539 An attacker might obviously use these two attacks in conjunction: It 540 will replace the responder's HI and RVS IP address by its owns in a 541 spoofed DNS packet sent to the initiator HI, then redirect all 542 exchanged packets to him and mount a MitM on HIP. In this case HIP 543 won't provide confidentiality nor initiator HI protection from 544 eavesdroppers. 546 8.2. Hash and HITs Collisions 548 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 549 by HIP to generate a HIT from an HI) eventually become insecure, 550 because an exploit has been found in which an attacker with a 551 reasonable computation power breaks one of the security features of 552 the hash (e.g. its supposed collision resistance.) This is why a HIP 553 end-node implementation SHOULD NOT authenticate its HIP peers based 554 solely on a HIT retrieved from DNS, but SHOULD rather use HI-based 555 authentication. 557 8.3. DNSSEC 559 In the absence of DNSSEC, the HIP RR is subject to the threats 560 described in RFC 3833 [RFC3833]. 562 9. IANA Considerations 564 IANA should allocate one new RR type code for the HIP RR from the 565 standard RR type space. 567 IANA does not need to open a new registry for public key algorithms 568 of the HIP RR because the HIP RR reuses "algorithms types" defined 569 for the IPSECKEY RR [RFC4025]. The presently defined values are 570 shown here for reference: 572 0 is reserved 574 1 is RSA 576 2 is DSA 578 10. Acknowledgments 580 As usual in the IETF, this document is the result of a collaboration 581 between many people. The authors would like to thanks the author 582 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 583 [RFC4025] specification, which this document was framed after. The 584 authors would also like to thanks the following people, who have 585 provided thoughtful and helpful discussions and/or suggestions, that 586 have helped improving this document: Rob Austein, Hannu Flinck, Tom 587 Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, 588 and Gabriel Montenegro. Some parts of this draft stem from 589 [I-D.ietf-hip-base]. 591 Julien Laganier is partly funded by Ambient Networks, a research 592 project supported by the European Commission under its Sixth 593 Framework Program. The views and conclusions contained herein are 594 those of the authors and should not be interpreted as necessarily 595 representing the official policies or endorsements, either expressed 596 or implied, of the Ambient Networks project or the European 597 Commission. 599 11. References 601 11.1. Normative references 603 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 604 STD 13, RFC 1034, November 1987. 606 [RFC1035] Mockapetris, P., "Domain names - implementation and 607 specification", STD 13, RFC 1035, November 1987. 609 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 610 Extensions", RFC 2065, January 1997. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 616 (DNS)", RFC 2536, March 1999. 618 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 619 Name System (DNS)", RFC 3110, May 2001. 621 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 622 Hain, "Representing Internet Protocol version 6 (IPv6) 623 Addresses in the Domain Name System (DNS)", RFC 3363, 624 August 2002. 626 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 627 Encodings", RFC 3548, July 2003. 629 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 630 "DNS Extensions to Support IP Version 6", RFC 3596, 631 October 2003. 633 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 634 Material in DNS", RFC 4025, March 2005. 636 [I-D.ietf-hip-base] 637 Moskowitz, R., "Host Identity Protocol", 638 draft-ietf-hip-base-04 (work in progress), October 2005. 640 [I-D.ietf-hip-rvs] 641 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 642 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 643 progress), October 2005. 645 11.2. Informative references 647 [I-D.ietf-hip-arch] 648 Moskowitz, R. and P. Nikander, "Host Identity Protocol 649 Architecture", draft-ietf-hip-arch-03 (work in progress), 650 August 2005. 652 [I-D.ietf-hip-mm] 653 Nikander, P., "End-Host Mobility and Multihoming with the 654 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 655 progress), July 2005. 657 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 658 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 659 October 1998. 661 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 662 Name System (DNS)", RFC 3833, August 2004. 664 Authors' Addresses 666 Pekka Nikander 667 Ericsson Research Nomadic Lab 668 JORVAS FIN-02420 669 FINLAND 671 Phone: +358 9 299 1 672 Email: pekka.nikander@nomadiclab.com 674 Julien Laganier 675 DoCoMo Communications Laboratories Europe GmbH 676 Landsberger Strasse 312 677 Munich 80687 678 Germany 680 Phone: +49 89 56824 231 681 Email: julien.ietf@laposte.net 682 URI: http://www.docomolab-euro.com/ 684 Intellectual Property Statement 686 The IETF takes no position regarding the validity or scope of any 687 Intellectual Property Rights or other rights that might be claimed to 688 pertain to the implementation or use of the technology described in 689 this document or the extent to which any license under such rights 690 might or might not be available; nor does it represent that it has 691 made any independent effort to identify any such rights. Information 692 on the procedures with respect to rights in RFC documents can be 693 found in BCP 78 and BCP 79. 695 Copies of IPR disclosures made to the IETF Secretariat and any 696 assurances of licenses to be made available, or the result of an 697 attempt made to obtain a general license or permission for the use of 698 such proprietary rights by implementers or users of this 699 specification can be obtained from the IETF on-line IPR repository at 700 http://www.ietf.org/ipr. 702 The IETF invites any interested party to bring to its attention any 703 copyrights, patents or patent applications, or other proprietary 704 rights that may cover technology that may be required to implement 705 this standard. Please address the information to the IETF at 706 ietf-ipr@ietf.org. 708 Disclaimer of Validity 710 This document and the information contained herein are provided on an 711 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 712 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 713 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 714 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 715 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 718 Copyright Statement 720 Copyright (C) The Internet Society (2006). This document is subject 721 to the rights, licenses and restrictions contained in BCP 78, and 722 except as set forth therein, the authors retain all their rights. 724 Acknowledgment 726 Funding for the RFC Editor function is currently provided by the 727 Internet Society.