draft-ietf-hip-rfc5205-bis-03.txt   draft-ietf-hip-rfc5205-bis-04.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5205 (if approved) December 11, 2013 Obsoletes: 5205 (if approved) January 16, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: June 14, 2014 Expires: July 20, 2014
Host Identity Protocol (HIP) Domain Name System (DNS) Extension Host Identity Protocol (HIP) Domain Name System (DNS) Extension
draft-ietf-hip-rfc5205-bis-03 draft-ietf-hip-rfc5205-bis-04
Abstract Abstract
This document specifies a new resource record (RR) for the Domain This document specifies a new resource record (RR) for the Domain
Name System (DNS), and how to use it with the Host Identity Protocol 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 (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 Identity (HI, the public component of the node public-private key
pair), Host Identity Tag (HIT, a truncated hash of its public key), pair), Host Identity Tag (HIT, a truncated hash of its public key),
and the Domain Names of its rendezvous servers (RVSs). This document and the Domain Names of its rendezvous servers (RVSs). This document
obsoletes RFC5205. obsoletes RFC5205.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 14, 2014. This Internet-Draft will expire on July 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5 3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7 4. Overview of Using the DNS with HIP . . . . . . . . . . . . . 7
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8 4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 7
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8 4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 8
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 10 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . 9
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10 5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10 5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 10 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 12 8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . 12
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative references . . . . . . . . . . . . . . . . . . 14 12.1. Normative references . . . . . . . . . . . . . . . . . . 14
12.2. Informative references . . . . . . . . . . . . . . . . . 15 12.2. Informative references . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 15 Appendix A. Changes from RFC 5205 . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies a new resource record (RR) for the Domain This document specifies a new resource record (RR) for the Domain
Name System (DNS) [RFC1034], and how to use it with the Host Identity 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 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 to store in the DNS its Host Identity (HI, the public component of
the node public-private key pair), Host Identity Tag (HIT, a the node public-private key pair), Host Identity Tag (HIT, a
truncated hash of its HI), and the Domain Names of its rendezvous truncated hash of its HI), and the Domain Names of its rendezvous
servers (RVSs) [I-D.ietf-hip-rfc5204-bis]. servers (RVSs) [I-D.ietf-hip-rfc5204-bis].
skipping to change at page 10, line 16 skipping to change at page 10, line 11
The PK length indicates the length in bytes of the Public key field. The PK length indicates the length in bytes of the Public key field.
This is a 16-bit unsigned integer in network byte order. This is a 16-bit unsigned integer in network byte order.
5.4. HIT Format 5.4. HIT Format
The HIT is stored as a binary value in network byte order. The HIT is stored as a binary value in network byte order.
5.5. Public Key Format 5.5. Public Key Format
Both of the public key types defined in this document (RSA and DSA) Two of the public key types defined in this document (RSA and DSA)
reuse the public key formats defined for the IPSECKEY RR [RFC4025]. reuse the public key formats defined for the IPSECKEY RR [RFC4025].
The DSA key format is defined in RFC 2536 [RFC2536]. The DSA key format is defined in RFC 2536 [RFC2536].
The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
specification. specification.
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 5.6. Rendezvous Servers Format
The Rendezvous Servers field indicates one or more variable length The Rendezvous Servers field indicates one or more variable length
wire-encoded domain names of rendezvous server(s), as described in wire-encoded domain names of rendezvous server(s), as described in
Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self- 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 describing, so the length is implicit. The domain names MUST NOT be
compressed. The rendezvous server(s) are listed in order of compressed. The rendezvous server(s) are listed in order of
preference (i.e., first rendezvous server(s) are preferred), defining preference (i.e., first rendezvous server(s) are preferred), defining
an implicit order amongst rendezvous servers of a single RR. When an implicit order amongst rendezvous servers of a single RR. When
multiple HIP RRs are present at the same owner name, this implicit multiple HIP RRs are present at the same owner name, this implicit
skipping to change at page 13, line 44 skipping to change at page 13, line 44
In the absence of DNSSEC, the HIP RR is subject to the threats In the absence of DNSSEC, the HIP RR is subject to the threats
described in RFC 3833 [RFC3833]. described in RFC 3833 [RFC3833].
9. IANA Considerations 9. IANA Considerations
IANA has allocated one new RR type code (55) for the HIP RR from the IANA has allocated one new RR type code (55) for the HIP RR from the
standard RR type space. standard RR type space.
IANA does not need to open a new registry for public key algorithms IANA does not need to open a new registry for public key algorithms
of the HIP RR because the HIP RR reuses "algorithms types" defined of the HIP RR because the HIP RR reuses "algorithms types" defined
for the IPSECKEY RR [RFC4025]. Presently defined values are shown for the IPSECKEY RR [RFC4025]. Presently defined values are:
here for reference only:
0 is reserved 0 is reserved
1 is DSA 1 is DSA
2 is RSA 2 is RSA
In the future, if a new algorithm is to be used for the HIP RR, a new [IANA-TBD] is ECDSA
algorithm type and corresponding public key encoding should be
defined for the IPSECKEY RR. The HIP RR should reuse both the same
algorithm type and the same corresponding public key format as the
IPSECKEY RR.
10. Contributors 10. Contributors
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
earlier, experimental version of this specification [RFC5205]. earlier, experimental version of this specification [RFC5205].
11. Acknowledgments 11. Acknowledgments
As usual in the IETF, this document is the result of a collaboration As usual in the IETF, this document is the result of a collaboration
between many people. The authors would like to thank the author between many people. The authors would like to thank the author
skipping to change at page 14, line 41 skipping to change at page 14, line 35
12.1. Normative references 12.1. Normative references
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013. hip-rfc5201-bis-14 (work in progress), October 2013.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-03 (work
in progress), September 2012. in progress), December 2013.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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, March 1997.
skipping to change at page 15, line 30 skipping to change at page 15, line 23
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605, April
2012.
12.2. Informative references 12.2. Informative references
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999. (DNS)", RFC 2536, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001. Name System (DNS)", RFC 3110, May 2001.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
skipping to change at page 16, line 4 skipping to change at page 16, line 6
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205, (HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008. April 2008.
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008. with the Host Identity Protocol", RFC 5206, April 2008.
Appendix A. Changes from RFC 5205 Appendix A. Changes from RFC 5205
o Updated HIP references to revised HIP specifications. 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).
Author's Address Author's Address
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
 End of changes. 17 change blocks. 
19 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/