--- 1/draft-ietf-hip-rfc5205-bis-07.txt 2015-12-14 09:15:06.507460736 -0800 +++ 2/draft-ietf-hip-rfc5205-bis-08.txt 2015-12-14 09:15:06.547461722 -0800 @@ -1,19 +1,19 @@ Network Working Group J. Laganier Internet-Draft Luminate Wireless, Inc. -Obsoletes: 5205 (if approved) June 10, 2015 +Obsoletes: 5205 (if approved) December 14, 2015 Intended status: Standards Track -Expires: December 12, 2015 +Expires: June 16, 2016 Host Identity Protocol (HIP) Domain Name System (DNS) Extension - draft-ietf-hip-rfc5205-bis-07 + draft-ietf-hip-rfc5205-bis-08 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 (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. @@ -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 December 12, 2015. + This Internet-Draft will expire on June 16, 2016. Copyright Notice Copyright (c) 2015 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 @@ -71,33 +71,33 @@ 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 13 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative references . . . . . . . . . . . . . . . . . . 14 - 12.2. Informative references . . . . . . . . . . . . . . . . . 15 + 12.2. Informative references . . . . . . . . . . . . . . . . . 16 Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 - Protocol (HIP) [I-D.ietf-hip-rfc5201-bis]. 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]. + 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 address(es). 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 @@ -316,27 +316,27 @@ 4. Overview of Using the DNS with HIP 4.1. Storing HI, HIT, and RVS in the DNS For any HIP node, its Host Identity (HI), the associated Host Identity Tag (HIT), and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store a Host Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP - specification [I-D.ietf-hip-rfc5201-bis]. + specification [RFC7401]. Upon return of a HIP RR, a host MUST always calculate the HI- derivative HIT to be used in the HIP exchange, as specified in - Section 3 of the HIP specification [I-D.ietf-hip-rfc5201-bis], while - the HIT possibly embedded along SHOULD only be used as an - optimization (e.g., table lookup). + Section 3 of the HIP specification [RFC7401], while the HIT possibly + embedded along SHOULD only be used as an optimization (e.g., table + lookup). The HIP resource record may also contain one or more domain name(s) of rendezvous server(s) towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this resource record [I-D.ietf-hip-rfc5204-bis]. The rendezvous server field of the HIP resource record stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no rendezvous server is present in the HIP resource record stored at that owner name. Such situations occur @@ -359,21 +359,21 @@ 4.2. Initiating Connections Based on DNS Names On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS lookup returns HIP resource records. The HIP resource records have a Time To Live (TTL) associated with them. When the number of seconds that passed since the record was retrieved exceeds the record's TTL, the record MUST be considered to - be no longer valid and deleted by the entiry that retrieved it. If + be no longer valid and deleted by the entity that retrieved it. If access to the record is necessary to initiate communication with the entity to which the record corresponds, a new query MUST be be made to retrieve a fresh copy of the record. There may be multiple HIP RRs associated with a single name. It is outside the scope of this specification as to how a host chooses from between multiple RRs when more than one is returned. The RVS information may be copied and aligned across multiple RRs, or may be different for each one; a host MUST check that the RVS used is associated with the HI being used, when multiple choices are @@ -483,30 +483,30 @@ of the public key. 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). - The complete representation of the HPIHI record is: + 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] ) - When no RVSs are present, the representation of the HPIHI record is: + When no RVSs are present, the representation of the HIP record is: IN HIP ( pk-algorithm base16-encoded-hit base64-encoded-public-key ) 7. Examples In the examples below, the public key field containing no whitespace is wrapped since it does not fit in a single line of this document. @@ -629,91 +629,110 @@ As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author (Michael Richardson), contributors, and reviewers of the IPSECKEY RR [RFC4025] specification, after which this document was framed. The authors would also like to thank the following people, who have provided thoughtful and helpful discussions and/or suggestions, that have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this document stem from the HIP specification - [I-D.ietf-hip-rfc5201-bis]. + [RFC7401]. Finally, thanks Sheng Jiang for performing the Internet + Area Directorate review of this document in the course of the + publication process. 12. References 12.1. Normative references - [I-D.ietf-hip-rfc5201-bis] - Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, - "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- - hip-rfc5201-bis-20 (work in progress), October 2014. - [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) - Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work - in progress), December 2014. + Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work + in progress), June 2015. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. + Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, + . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. + DOI 10.17487/RFC3596, October 2003, + . [RFC4025] Richardson, M., "A Method for Storing IPsec Keying - Material in DNS", RFC 4025, March 2005. + Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March + 2005, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. + RFC 4034, DOI 10.17487/RFC4034, March 2005, + . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, October 2006. + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital - Signature Algorithm (DSA) for DNSSEC", RFC 6605, April - 2012. + Signature Algorithm (DSA) for DNSSEC", RFC 6605, + DOI 10.17487/RFC6605, April 2012, + . + + [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. + Henderson, "Host Identity Protocol Version 2 (HIPv2)", + RFC 7401, DOI 10.17487/RFC7401, April 2015, + . 12.2. Informative references - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. + [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, + . - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. + [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, + May 2001, . [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. + Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August + 2004, . [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol - (HIP) Architecture", RFC 4423, May 2006. + (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May + 2006, . [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, - April 2008. + DOI 10.17487/RFC5205, April 2008, + . [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. Appendix A. Changes from RFC 5205 o Updated HIP references to revised HIP specifications. o Extended DNS HIP RR to support for Host Identities based on Elliptic Curve Digital Signature Algorithm (ECDSA).