idnits 2.17.1 draft-ietf-hip-dns-06.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 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 714. ** 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 24, 2006) is 6628 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 466 == Unused Reference: 'RFC3363' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-arch' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-mm' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 665, 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 28, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 February 24, 2006 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-06 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 28, 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 contain 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 attempts 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 optionally 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. This 381 is an 8 bits unsigned integer. 383 5.2. PK algorithm format 385 The PK algorithm field indicates the public key cryptographic 386 algorithm and the implied public key field format. This is an 8 bits 387 unsigned integer. This document reuses the values defined for the 388 'algorithm type' of the IPSECKEY RR [RFC4025] 'gateway type' field. 390 The presently defined values are shown here for reference: 392 1 A DSA key is present, in the format defined in RFC2536 393 [RFC2536]. 395 2 A RSA key is present, in the format defined in RFC3110 396 [RFC3110]. 398 5.3. PK length format 400 The PK length indicates the length in bytes of the Public key field. 401 This is a 16 bits unsigned integer in network byte order. 403 5.4. HIT format 405 The HIT is stored, as a binary value, in network byte order. 407 5.5. Public key format 409 Both of the public key types defined in this document (RSA and DSA) 410 reuse the public key formats defined for the IPSECKEY RR [RFC4025] 411 (which in turns contains the algorithm-specific portion of the KEY RR 412 RDATA, all of the KEY RR DATA after the first four octets, 413 corresponding to the same portion of the KEY RR that must be 414 specified by documents that define a DNSSEC algorithm.) 416 In the future, if a new algorithm is to be used both by IPSECKEY RR 417 and HIP RR, it should use the same public key encoding for both RRs. 418 Unless specified otherwise, the HIP RR public key field SHOULD use 419 the same public key format as the IPSECKEY RR RDATA for the 420 corresponding algorithm. 422 The DSA key format is defined in RFC2536 [RFC2536]. 424 The RSA key format is defined in RFC3110 [RFC3110] and the RSA key 425 size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] 426 specification. 428 5.6. Rendezvous servers format 430 The Rendezvous servers field indicates one or more variable length 431 wire-encoded domain names rendezvous server(s), as described in 432 Section 3.3 of RFC1035 [RFC1035]. The wire-encoded format is self- 433 describing, so the length is implicit. The domain names MUST NOT be 434 compressed. The rendezvous server(s) are listed in order of 435 preference (i.e. first rendezvous server(s) are preferred). 437 6. HIP RR Presentation Format 439 This section specifies the representation of the HIP RR in a zone 440 data master file. 442 The HIT length field is not represented as it is implicitly known 443 thanks to the HIT field representation. 445 The PK algorithm field is represented as unsigned integers. 447 The PK length field is not represented as it is implicitly known 448 thanks to the Public key field representation. 450 The HIT field is represented as the Base16 encoding [RFC3548] (a.k.a. 451 hex or hexadecimal) of the HIT. The encoding MUST NOT contain 452 whitespace(s). 454 The Public Key field is represented as the Base64 encoding [RFC3548] 455 of the public key. The encoding MAY contain whitespace(s), and such 456 whitespace(s) MUST be ignored. 458 The Rendezvous servers field is represented by one or more 459 uncompressed domain name(s) 461 The complete representation of the HPIHI record is: 463 IN HIP ( pk-algorithm 464 base16-encoded-hit 465 base64-encoded-public-key 466 rendezvous-server[1] 467 ... 468 rendezvous-server[n] ) 470 7. Examples 472 Example of a node with HI and HIT but no RVS: 474 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 475 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv 476 M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy 477 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG 478 Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A 479 WkskmdHaVDP4BcelrTI3rMXdXF5D ) 481 Example of a node with a HI, HIT and one RVS: 483 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 484 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv 485 M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy 486 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG 487 Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A 488 WkskmdHaVDP4BcelrTI3rMXdXF5D 489 rvs.example.com ) 491 Example of a node with a HI, HIT and two RVS: 493 www.example.com. IN HIP ( 2 4009D9BA7B1A74DF365639CC39F1D578 494 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIv 495 M4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy 496 87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRG 497 Qb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48A 498 WkskmdHaVDP4BcelrTI3rMXdXF5D 499 rvs1.example.com 500 rvs2.example.com ) 502 8. Security Considerations 504 Though the security considerations of the HIP DNS extensions still 505 need to be more investigated and documented, this section contains a 506 description of the known threats involved with the usage of the HIP 507 DNS extensions. 509 In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS 510 Extensions allows to provision two HIP nodes with the public keying 511 material (HI) of their peer. These HIs will be subsequently used in 512 a key exchange between the peers. Hence, the HIP DNS Extensions 513 introduce the same kind of threats that IPSECKEY does, plus threats 514 caused by the possibility given to a HIP node to initiate or accept a 515 HIP exchange using "opportunistic" or "unpublished initiator HI" 516 modes. 518 A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure 519 channel insuring proper data integrity of the RRs. DNSSEC [RFC2065] 520 provides such a secure channel. 522 In the absence of a proper secure channel, both parties are 523 vulnerable to MitM and DoS attacks, and unrelated parties might be 524 subject to DoS attacks as well. These threats are described in the 525 following sections. 527 8.1. Attacker tampering with an insecure HIP RR 529 The HIP RR contains public keying material in the form of the named 530 peer's public key (the HI) and its secure hash (the HIT.) Both of 531 these are not sensitive to attacks where an adversary gains knowledge 532 of them. However, an attacker that is able to mount an active attack 533 on the DNS, i.e., tampers with this HIP RR (e.g. using DNS spoofing) 534 is able to mount Man-in-the-Middle attacks on the cryptographic core 535 of the eventual HIP exchange (responder's HIP RR rewritten by the 536 attacker.) 538 The HIP RR may contain a rendezvous server domain name resolved into 539 a destination IP address where the named peer is reachable by an I1 540 (HIP Rendezvous Extensions IPSECKEY RR [I-D.ietf-hip-rvs].) Thus, an 541 attacker able to tamper with this RR is able to redirect I1 packets 542 sent to the named peer to a chosen IP address, for DoS or MitM 543 attacks. Note that this kind of attack is not specific to HIP and 544 exists independently to whether or not HIP and the HIP RR are used. 545 Such an attacker might tamper with A and AAAA RRs as well. 547 An attacker might obviously use these two attacks in conjunction: It 548 will replace the responder's HI and RVS IP address by its owns in a 549 spoofed DNS packet sent to the initiator HI, then redirect all 550 exchanged packets to him and mount a MitM on HIP. In this case HIP 551 won't provide confidentiality nor initiator HI protection from 552 eavesdroppers. 554 8.2. Hash and HITs Collisions 556 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 557 by HIP to generate a HIT from an HI) eventually become insecure, 558 because an exploit has been found in which an attacker with a 559 reasonable computation power breaks one of the security features of 560 the hash (e.g. its supposed collision resistance.) This is why a HIP 561 end-node implementation SHOULD NOT authenticate its HIP peers based 562 solely on a HIT retrieved from DNS, but SHOULD rather use HI-based 563 authentication. 565 8.3. DNSSEC 567 In the absence of DNSSEC, the HIP RR is subject to the threats 568 described in RFC 3833 [RFC3833]. 570 9. IANA Considerations 572 IANA should allocate one new RR type code (TBD, 55?) for the HIP RR 573 from the standard RR type space. 575 IANA does not need to open a new registry for public key algorithms 576 of the HIP RR because the HIP RR reuses "algorithms types" defined 577 for the IPSECKEY RR [RFC4025]. The presently defined values are 578 shown here for reference: 580 0 is reserved 582 1 is RSA 584 2 is DSA 586 10. Acknowledgments 588 As usual in the IETF, this document is the result of a collaboration 589 between many people. The authors would like to thanks the author 590 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 591 [RFC4025] specification, which this document was framed after. The 592 authors would also like to thanks the following people, who have 593 provided thoughtful and helpful discussions and/or suggestions, that 594 have helped improving this document: Jeff Ahrenholz, Rob Austein, 595 Hannu Flinck, Tom Henderson, Olaf Kolkman, Miika Komu, Andrew 596 McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this 597 draft stem from [I-D.ietf-hip-base]. 599 Julien Laganier is partly funded by Ambient Networks, a research 600 project supported by the European Commission under its Sixth 601 Framework Program. The views and conclusions contained herein are 602 those of the authors and should not be interpreted as necessarily 603 representing the official policies or endorsements, either expressed 604 or implied, of the Ambient Networks project or the European 605 Commission. 607 11. References 609 11.1. Normative references 611 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 612 STD 13, RFC 1034, November 1987. 614 [RFC1035] Mockapetris, P., "Domain names - implementation and 615 specification", STD 13, RFC 1035, November 1987. 617 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 618 Extensions", RFC 2065, January 1997. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 624 (DNS)", RFC 2536, March 1999. 626 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 627 Name System (DNS)", RFC 3110, May 2001. 629 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 630 Hain, "Representing Internet Protocol version 6 (IPv6) 631 Addresses in the Domain Name System (DNS)", RFC 3363, 632 August 2002. 634 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 635 Encodings", RFC 3548, July 2003. 637 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 638 "DNS Extensions to Support IP Version 6", RFC 3596, 639 October 2003. 641 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 642 Material in DNS", RFC 4025, March 2005. 644 [I-D.ietf-hip-base] 645 Moskowitz, R., "Host Identity Protocol", 646 draft-ietf-hip-base-04 (work in progress), October 2005. 648 [I-D.ietf-hip-rvs] 649 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 650 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 651 progress), October 2005. 653 11.2. Informative references 655 [I-D.ietf-hip-arch] 656 Moskowitz, R. and P. Nikander, "Host Identity Protocol 657 Architecture", draft-ietf-hip-arch-03 (work in progress), 658 August 2005. 660 [I-D.ietf-hip-mm] 661 Nikander, P., "End-Host Mobility and Multihoming with the 662 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 663 progress), July 2005. 665 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 666 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 667 October 1998. 669 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 670 Name System (DNS)", RFC 3833, August 2004. 672 Authors' Addresses 674 Pekka Nikander 675 Ericsson Research Nomadic Lab 676 JORVAS FIN-02420 677 FINLAND 679 Phone: +358 9 299 1 680 Email: pekka.nikander@nomadiclab.com 682 Julien Laganier 683 DoCoMo Communications Laboratories Europe GmbH 684 Landsberger Strasse 312 685 Munich 80687 686 Germany 688 Phone: +49 89 56824 231 689 Email: julien.ietf@laposte.net 690 URI: http://www.docomolab-euro.com/ 692 Intellectual Property Statement 694 The IETF takes no position regarding the validity or scope of any 695 Intellectual Property Rights or other rights that might be claimed to 696 pertain to the implementation or use of the technology described in 697 this document or the extent to which any license under such rights 698 might or might not be available; nor does it represent that it has 699 made any independent effort to identify any such rights. Information 700 on the procedures with respect to rights in RFC documents can be 701 found in BCP 78 and BCP 79. 703 Copies of IPR disclosures made to the IETF Secretariat and any 704 assurances of licenses to be made available, or the result of an 705 attempt made to obtain a general license or permission for the use of 706 such proprietary rights by implementers or users of this 707 specification can be obtained from the IETF on-line IPR repository at 708 http://www.ietf.org/ipr. 710 The IETF invites any interested party to bring to its attention any 711 copyrights, patents or patent applications, or other proprietary 712 rights that may cover technology that may be required to implement 713 this standard. Please address the information to the IETF at 714 ietf-ipr@ietf.org. 716 Disclaimer of Validity 718 This document and the information contained herein are provided on an 719 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 720 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 721 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 722 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 723 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 724 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 726 Copyright Statement 728 Copyright (C) The Internet Society (2006). This document is subject 729 to the rights, licenses and restrictions contained in BCP 78, and 730 except as set forth therein, the authors retain all their rights. 732 Acknowledgment 734 Funding for the RFC Editor function is currently provided by the 735 Internet Society.