[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

                                               R. Moskowitz, ICSA, Inc.
Internet Draft
Document: <draft-moskowitz-hip-dns-00.txt>               June 1999

                   Storage of HIP information in DNS

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

1. Abstract

   This memo describes how HIP Public Key Hashes [HIP], and public keys
   can be stored in DNS.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in [RFC-2119].

3. Introduction

   HIP is designed to work with Public Key technology like DSA.  It
   does not use X.509 certificates to hold and transport these keys,
   nor to authenticate the owner of the keys.  In those cases where it
   is desired to authenticate the owner of the HIP keys, DNS can be
   used as the storage media and the retrieval mechanism.

4. Background

Moskowitz                                                            1

                  Storage of HIP information in DNS         June 1999

   One of the design goals of HIP was to provide for reliable host
   identifiers, but also to allow for anonymous behavior where desired.
   The later was achieved in the basic structure of HIP where identity
   is pasted in band in the HIP payload.  This identity can be as much
   or as little as desired, and it is not internally authenticatable.

   The common practice in most protocols is to provide authenticated
   identity via X.509 certificates.  The basic design of HIP, that is
   its heavy use of DNS record formats, lends it to using secure DNS
   [DNSSEC] as its preferred media for host authentication.

5. DNS Resource Records used by HIP

   A number of RR are defined in the HIP protocol.  Most notably DSA
   RRs and NULL (or name) RRs.  D-H RRs are also used to enable
   encryption [HIP ENC].  Whereas the DSA RR is the principle RR used
   to provide the DSA public key, the NULL RR is simply used to convey
   an FQDN without any additional baggage.

   The RRs that would minimally be placed in DNS would be DSA, A, and
   SIG.  An A record is not used when there is no binding of an IP
   address with the host.  Examples of this are multi-homed hosts and
   dial up hosts.

5.1. DSA Resource Records

   DSA RRs [DSA RR] are the primary resource records in HIP.  By
   placing this information in DNS, the host that receives the DSA RR
   in band will be able to authenticate the information and establish a
   trust identity for the sending host.

5.2. Host names

   A host name is needed with the DSA record and any other record in
   DNS [DNS].  Since this particular usage of DNS is for HIP
   authentication, the host name SHOULD contain the HIP Public Key Hash
   (PKH). Given a PKH of: 1385 D17F C639 61F5, the host name SHOULD be
   1385.D17F.C639.61F5, making the Full Qualified Domain Name something
   like 1385.D17F.C639.61F5.HIP.foo.tld.  Since names in DNS can have
   dots, there is no need to maintain an artificial hierarchy for the
   apparent three 'zones' within the host name.  The use of the dot
   here is not to represent DNS zones, but rather a sound convention
   for representing the PKH.  This follows a frequent practice found in
   IN-ADDR-ARPA records in some networks that have B or A class address

5.3. A Resource Records

   The A record associates the name of the host with its IP address.
   AN A record should only be used where there is an IP address for
   such a binding.  The A record is optional.  For those hosts that

Moskowitz                                                            2

                  Storage of HIP information in DNS         June 1999

   have multiple addresses, use dynamic addresses, or are behind a NAT,
   the A record SHOULD be omitted.

   The host has the FQDN for DNS query either from the HIP payload, or
   from information previously loaded in the host.

5.4. SIG Resource Records

   Since the purpose of using DNS is to provide authentication of the
   DSA RR, the SIG record MUST be present.

6. Security Considerations

   HIP is using DNS to authenticate the public keys used.  Thus DNSSEC
   MUST be used to protect all associated DNS records.

7. IANA Considerations

   There are no additional IANA Considerations beyond those in IPsec
   and HIP.

8. References

   [HIP], Moskowitz, R., "The Host Identity Payload", draft-ietf-
   moskowitz-HIP-00.txt, May 1999.

   [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

   [HIP_ENC], Moskowitz, R., "ESP Encryption support in HIP", draft-
   ietf-moskowitz-HIP-ENC-00.txt, May 1999.

   [DNS], Mockapetris, P., "Domain Names - Implementation And
   Specification", RFC 1035, November 1987.

   [DNSSEC], Eastlake, D., "Domain Name System Security Extensions",
   RFC 2535, March 1999.

   [DSA_RR], Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
   (DNS)", RFC 2536, March 1999.

9. Acknowledgments

   The original thoughts on DNS storage of HIP information were
   properly shredded by Keith Moore, Patrik F„ltstr÷m, Harald
   Alvestrand, and Hugh Daniels.  Further conversations with Hugh lead
   to this simpler, more manageable model.

10. Author's Addresses

Moskowitz                                                            3

                  Storage of HIP information in DNS         June 1999

   Robert Moskowitz
   ICSA, Inc.
   1200 Walnut Bottom Rd.
   Carlisle, PA  17013
   Email: rgm@icsa.net

Moskowitz                                                            4

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/