--- 1/draft-ietf-hip-rfc5205-bis-09.txt 2016-08-04 18:17:53.205311107 -0700 +++ 2/draft-ietf-hip-rfc5205-bis-10.txt 2016-08-04 18:17:53.245312112 -0700 @@ -1,24 +1,24 @@ Network Working Group J. Laganier Internet-Draft Luminate Wireless, Inc. -Obsoletes: 5205 (if approved) January 31, 2016 +Obsoletes: 5205 (if approved) August 4, 2016 Intended status: Standards Track -Expires: August 3, 2016 +Expires: February 5, 2017 Host Identity Protocol (HIP) Domain Name System (DNS) Extension - draft-ietf-hip-rfc5205-bis-09 + draft-ietf-hip-rfc5205-bis-10 Abstract - This document specifies a new resource record (RR) for the Domain - Name System (DNS), and how to use it with the Host Identity Protocol + This document specifies a resource record (RR) for the Domain Name + System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 3, 2016. + This Internet-Draft will expire on February 5, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,54 +62,54 @@ 4.2. Initiating Connections Based on DNS Names . . . . . . . . 8 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 10 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 10 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10 5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10 5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 11 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13 - 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13 + 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 14 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 12.1. Normative references . . . . . . . . . . . . . . . . . . 14 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12.1. Normative references . . . . . . . . . . . . . . . . . . 15 12.2. Informative references . . . . . . . . . . . . . . . . . 16 - Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 + Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 18 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction - This document specifies a new resource record (RR) for the Domain - Name System (DNS) [RFC1034], and how to use it with the Host Identity + This document specifies a resource record (RR) for the Domain Name + System (DNS) [RFC1034], and how to use it with the Host Identity Protocol (HIP) [RFC7401]. This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public- private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Names of its rendezvous servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP addresses. This step occurs prior to communication with the remote host, and relies on a DNS lookup. With HIP, IP addresses are intended to be used mostly for on-the-wire communication between end hosts, while most Upper Layer Protocols (ULP) and applications use HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this - translation is pretty straightforward: We define a new HIP resource + translation is pretty straightforward: We define a HIP resource record. Upon query by an application or ULP for a name to IP address lookup, the resolver would then additionally perform a name to HI lookup, and use it to construct the resulting HI to IP address mapping (which is internal to the HIP layer). The HIP layer uses the HI to IP address mapping to translate HIs and HITs into IP addresses and vice versa. The HIP specification [RFC7401] specifies the HIP base exchange between a HIP Initiator and a HIP Responder based on a four-way handshake involving a total of four HIP packets (I1, R1, I2, and R2). @@ -119,21 +119,21 @@ The HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis] allows a HIP node to be reached via the IP address(es) of a third party, the node's rendezvous server (RVS). An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP base exchange by sending the I1 packet initiating the exchange towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of a rendezvous server for a given host name. - This document introduces the new HIP DNS resource record to store the + This document introduces the HIP DNS resource record to store the Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag (HIT) information. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Usage Scenarios @@ -161,21 +161,21 @@ The HIP RR is class independent. When a HIP node wants to initiate communication with another HIP node, it first needs to perform a HIP base exchange to set up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without prior knowledge of the Responder's HI, by doing so both nodes knowingly risk man-in-the- middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtains the HI of the Responder, and then initiates the exchange. This can be done, for example, - through manual configuration or DNS lookups. Hence, a new HIP RR is + through manual configuration or DNS lookups. Hence, a HIP RR is introduced. When a HIP node is frequently changing its IP address(es), the natural DNS latency for propagating changes may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP Architecture [RFC4423] introduces rendezvous servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. A HIP host uses a rendezvous server as a rendezvous point to maintain reachability with possible HIP Initiators while moving [RFC5206]. Such a HIP node would publish in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS @@ -459,54 +459,67 @@ In addition, this document similarly defines the public key format of type ECDSA as the algorithm-specific portion of the DNSKEY RR RDATA for ECDSA [RFC6605], i.e, all of the DNSKEY RR DATA after the first four octets, corresponding to the same portion of the DNSKEY RR that must be specified by documents that define a DNSSEC algorithm. 5.6. Rendezvous Servers Format The Rendezvous Servers field indicates one or more variable length - wire-encoded domain names of rendezvous server(s), as described in - Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self- - describing, so the length is implicit. The domain names MUST NOT be - compressed. The rendezvous server(s) are listed in order of - preference (i.e., first rendezvous server(s) are preferred), defining - an implicit order amongst rendezvous servers of a single RR. When - multiple HIP RRs are present at the same owner name, this implicit - order of rendezvous servers within an RR MUST NOT be used to infer a - preference order between rendezvous servers stored in different RRs. + wire-encoded domain names of rendezvous server(s), concatenated, and + encoded as described in Section 3.3 of RFC 1035 [RFC1035]: " is a domain name represented as a series of labels, and + terminated by a label with zero length". Since the wire-encoded + format is self-describing, the length of each domain-name is + implicit: The zero length label termination serves as a separator + between multiple rendezvous server domain names concatenated in the + Rendezvous Servers field of a same HIP RR. Since the length of the + other portion of the RR's RRDATA is known, and the overall length of + the RR's RDATA is also known (RDLENGTH), all the length information + necessary to parse the HIP RR is available. + + The domain names MUST NOT be compressed. The rendezvous server(s) + are listed in order of preference (i.e., first rendezvous server(s) + are preferred), defining an implicit order amongst rendezvous servers + of a single RR. When multiple HIP RRs are present at the same owner + name, this implicit order of rendezvous servers within an RR MUST NOT + be used to infer a preference order between rendezvous servers stored + in different RRs. 6. HIP RR Presentation Format This section specifies the representation of the HIP RR in a zone master file. The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation. The PK algorithm field is represented as unsigned integers. The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to distinguish it from the public key field. - The Public Key field is represented as the Base64 encoding [RFC4648] - of the public key. The encoding MUST NOT contain whitespace(s) to - distinguish it from the Rendezvous Servers field. + The Public Key field is represented as the Base64 encoding of the + public key, as defined in Section 4 of [RFC4648]. The encoding MUST + NOT contain whitespace(s) to distinguish it from the Rendezvous + Servers field. The PK length field is not represented, as it is implicitly known thanks to the Public key field representation containing no whitespaces. The Rendezvous Servers field is represented by one or more domain - name(s) separated by whitespace(s). + name(s) separated by whitespace(s). These whitespace(s) are only + used in the HIP RR representation format, and are not part of the HIP + RR wire format. The complete representation of the HIP record is: IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key rendezvous-server[1] ... rendezvous-server[n] ) @@ -615,27 +627,46 @@ based solely on a HIT retrieved from the DNS, but SHOULD rather use HI-based authentication. 8.3. DNSSEC In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833]. 9. IANA Considerations - IANA is requested to replace references to [RFC5205] by references to - this document in the the DNS RR type code registry. + [RFC5205], obsoleted by this document, made the following definition + and reservation in the IANA Registry for DNS RR Types: - IANA is requested to allocate the following algorithm type in the - IPSECKEY RR [RFC4025] registry: + Value Type + ----- ---- + 55 HIP - [IANA-TBD] is ECDSA + This document updates the IANA Registry for DNS RR Types by replacing + references to [RFC5205] by references to this document. + + As [RFC5205], this document reuses the Algorithm Types defined by + [RFC4025] for the IPSEC KEY RR. Presently defined values are shown + here for reference only: + + Value Description + ----- -------------------------------------------------------- + 1 A DSA key is present, in the format defined in [RFC2536] + 2 A RSA key is present, in the format defined in [RFC3110] + + IANA is requested to make the following Algorithm Type reservation + and definition in the IANA Registry for the IPSECKEY RR [RFC4025] + Algorithm Types: + + Value Description + -------- ----------- + TBD-IANA An ECDSA key is present, in the format defined in [RFC6605] 10. Contributors Pekka Nikander co-authored an earlier, experimental version of this specification [RFC5205]. 11. Acknowledgments As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author @@ -747,18 +778,28 @@ o Extended DNS HIP RR to support for Host Identities based on Elliptic Curve Digital Signature Algorithm (ECDSA). o Clarified that new query must be made when the time that passed since a RR was retrieved exceeds the TTL of the RR. o Added considerations related to multiple HIP RRs being associated with a single name. + o Clarified that the Base64 encoding in use is as per Section 4 of + [RFC4648]. + + o Clarified the wire format when more than one rendezvous servers + are defined in one RR. + + o Clarified that "whitespace" is used as the delimiter in the human- + readable representation of the RR but is not part of the wire + format. + Author's Address Julien Laganier Luminate Wireless, Inc. Cupertino, CA USA EMail: julien.ietf@gmail.com