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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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 blocks. 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 Fltstr÷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