idnits 2.17.1 draft-moskowitz-hip-dns-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 238 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([HIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9075 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HIP ENC' is mentioned on line 68, but not defined == Missing Reference: 'DSA RR' is mentioned on line 79, but not defined -- No information found for draft-ietf-moskowitz-HIP - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIP' ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Moskowitz, ICSA, Inc. 2 Internet Draft 3 Document: June 1999 5 Storage of HIP information in DNS 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 This memo describes how HIP Public Key Hashes [HIP], and public keys 31 can be stored in DNS. 33 2. Conventions used in this document 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 37 this document are to be interpreted as described in [RFC-2119]. 39 3. Introduction 41 HIP is designed to work with Public Key technology like DSA. It 42 does not use X.509 certificates to hold and transport these keys, 43 nor to authenticate the owner of the keys. In those cases where it 44 is desired to authenticate the owner of the HIP keys, DNS can be 45 used as the storage media and the retrieval mechanism. 47 4. Background 49 Moskowitz 1 51 Storage of HIP information in DNS June 1999 53 One of the design goals of HIP was to provide for reliable host 54 identifiers, but also to allow for anonymous behavior where desired. 55 The later was achieved in the basic structure of HIP where identity 56 is pasted in band in the HIP payload. This identity can be as much 57 or as little as desired, and it is not internally authenticatable. 59 The common practice in most protocols is to provide authenticated 60 identity via X.509 certificates. The basic design of HIP, that is 61 its heavy use of DNS record formats, lends it to using secure DNS 62 [DNSSEC] as its preferred media for host authentication. 64 5. DNS Resource Records used by HIP 66 A number of RR are defined in the HIP protocol. Most notably DSA 67 RRs and NULL (or name) RRs. D-H RRs are also used to enable 68 encryption [HIP ENC]. Whereas the DSA RR is the principle RR used 69 to provide the DSA public key, the NULL RR is simply used to convey 70 an FQDN without any additional baggage. 72 The RRs that would minimally be placed in DNS would be DSA, A, and 73 SIG. An A record is not used when there is no binding of an IP 74 address with the host. Examples of this are multi-homed hosts and 75 dial up hosts. 77 5.1. DSA Resource Records 79 DSA RRs [DSA RR] are the primary resource records in HIP. By 80 placing this information in DNS, the host that receives the DSA RR 81 in band will be able to authenticate the information and establish a 82 trust identity for the sending host. 84 5.2. Host names 86 A host name is needed with the DSA record and any other record in 87 DNS [DNS]. Since this particular usage of DNS is for HIP 88 authentication, the host name SHOULD contain the HIP Public Key Hash 89 (PKH). Given a PKH of: 1385 D17F C639 61F5, the host name SHOULD be 90 1385.D17F.C639.61F5, making the Full Qualified Domain Name something 91 like 1385.D17F.C639.61F5.HIP.foo.tld. Since names in DNS can have 92 dots, there is no need to maintain an artificial hierarchy for the 93 apparent three 'zones' within the host name. The use of the dot 94 here is not to represent DNS zones, but rather a sound convention 95 for representing the PKH. This follows a frequent practice found in 96 IN-ADDR-ARPA records in some networks that have B or A class address 97 blocks. 99 5.3. A Resource Records 101 The A record associates the name of the host with its IP address. 102 AN A record should only be used where there is an IP address for 103 such a binding. The A record is optional. For those hosts that 105 Moskowitz 2 107 Storage of HIP information in DNS June 1999 109 have multiple addresses, use dynamic addresses, or are behind a NAT, 110 the A record SHOULD be omitted. 112 The host has the FQDN for DNS query either from the HIP payload, or 113 from information previously loaded in the host. 115 5.4. SIG Resource Records 117 Since the purpose of using DNS is to provide authentication of the 118 DSA RR, the SIG record MUST be present. 120 6. Security Considerations 122 HIP is using DNS to authenticate the public keys used. Thus DNSSEC 123 MUST be used to protect all associated DNS records. 125 7. IANA Considerations 127 There are no additional IANA Considerations beyond those in IPsec 128 and HIP. 130 8. References 132 [HIP], Moskowitz, R., "The Host Identity Payload", draft-ietf- 133 moskowitz-HIP-00.txt, May 1999. 135 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 136 Requirement Levels", RFC 2119, Harvard University, March 1997 138 [HIP_ENC], Moskowitz, R., "ESP Encryption support in HIP", draft- 139 ietf-moskowitz-HIP-ENC-00.txt, May 1999. 141 [DNS], Mockapetris, P., "Domain Names - Implementation And 142 Specification", RFC 1035, November 1987. 144 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 145 RFC 2535, March 1999. 147 [DSA_RR], Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 148 (DNS)", RFC 2536, March 1999. 150 9. Acknowledgments 152 The original thoughts on DNS storage of HIP information were 153 properly shredded by Keith Moore, Patrik F�ltstr�m, Harald 154 Alvestrand, and Hugh Daniels. Further conversations with Hugh lead 155 to this simpler, more manageable model. 157 10. Author's Addresses 159 Moskowitz 3 161 Storage of HIP information in DNS June 1999 163 Robert Moskowitz 164 ICSA, Inc. 165 1200 Walnut Bottom Rd. 166 Carlisle, PA 17013 167 Email: rgm@icsa.net 169 Moskowitz 4