idnits 2.17.1 draft-watson-dhc-serv-verify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There is 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 134 has weird spacing: '...ed Name dom...' == Line 181 has weird spacing: '...her the opera...' == Line 193 has weird spacing: '...MUST be disca...' == Line 202 has weird spacing: '...packets deliv...' -- 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 (July 30, 1997) is 9760 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: 'DHCP' is mentioned on line 57, but not defined == Unused Reference: 'RFC2131' is defined on line 295, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) -- Possible downref: Normative reference to a draft: ref. 'DHCPSEC' == Outdated reference: A later version (-13) exists of draft-ietf-dnsind-tsig-02 Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Robert Watson (TIS) 2 Olafur Gudmundsson (TIS) 3 July 30, 1997 5 DHCP Server Verification by Client Via DNSSEC 6 8 Status of this Document 10 This draft, file name draft-watson-dhc-serv-verify-00.txt is 11 intended to be become an Proposed Standard RFC. Distribution of 12 this document is unlimited. Comments should be sent to the 13 authors. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet-Drafts as reference material or to cite them other than 24 as a ``working draft'' or ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 29 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 30 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 32 Abstract 34 The document defines a mechanism to allow a DHCP client to verify 35 the authenticity of a DHCP server configuration offer using 36 DNSSEC. Currently DHCP clients have no way to assess which of 37 DHCP OFFERS are from valid DHCP servers, and which are not. 38 Malicious DHCP servers can cause various network problems for 39 unsuspecting clients. 41 In order to support DHCP server authorization a new DNS Resource 42 Record type (ALLOC) is added. Using the ALLOC record in combination 43 with the servers KEY record the client can authoritatively assess if 44 the server is authorized. 46 1. Introduction 48 The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 49 hierarchal distributed database system that provides information 50 fundamental to Internet operations, such as name <=> address 51 translation and mail handling information. DNS has recently 52 been extended [RFC2065] to provide for data origin 53 authentication, public key distribution, and query and 54 transaction authentication, all based on public key cryptography and 55 public key based digital signatures. 57 The Dynamic Host Configuration Protocol (DHCP) [DHCP] can provide 58 the essential configuration to a new host such that it can 59 interact with the network. This usually includes any TCP/IP 60 parameters needed to establish communication as well as network 61 server information, usually including DHCP server, DNS servers, 62 WINS server, TFTP server, and others. DHCP servers typically 63 restrict address allocation based on the identity of the 64 requesting entity, and DHCP security will address this 65 authentication. 67 However, there is no easy way for a client to verify that the server 68 it is communicating with is a valid DHCP server without 69 preconfigured information about which servers are valid. If 70 multiple server requests are received, it is conceivable that 71 one may be the result of a malicious entity trying to cause 72 network problems by misconfiguring hosts. A shared secret with 73 known DHCP servers is reasonable, but for mobile IP hosts 74 connecting to multiple service providers, this is not feasible. 75 Without such verification, serious security problems can entail. 76 An unauthorized server could define routing and DNS information 77 maliciously, making all client communications pass through the 78 server. A DHCP signature option for authentication has been 79 defined [DHCPSEC]. 81 1.1 DNS Considerations 83 With DNS Security, all hosts will be preconfigured with a root DNS 84 key, or a Transaction Signature (TSIG) [TSIG] shared secret for 85 communication with a DNS server. For hosts with a root key, it 86 is possible to verify the server's authenticity in offering an 87 IP address. Associated with all verifiable addresses will be a 88 list of authorized FQDNs for hosts. Once some type of 89 preliminary communication is established (either by trusting the 90 DHCP server for some minimal level, or by an undefined post-DHCP or 91 in-DHCP protocol), DNSSEC can be used to extract the hostname and 92 key of the server, if they are listed as an authorized server. 93 Thus, by using the root key and DNSSEC, a chain of authority can 94 be employed to verify that the DHCP server authorized the 95 update. The identity of the DHCP server can be verified by 96 checking the digital signature to the DHCPOFFER packet using a 97 DNSSEC private key of the host, which can then be verified using 98 the DNSSEC public key retrieved using the allocation resource 99 record. 101 The allocation record is associated with the reverse lookup record 102 for an IP address in the IN-ADDR.ARPA. domain, and when 103 retrieved, returns a list of FQDNs that are acceptable. Both 104 the construction of ALLOC RRs and their use in authenticating IP 105 address allocation are discussed in this document. 107 1.2 Keywords Used 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119. 113 2. IP Address Address Allocation Resource Record Format 115 To provide storage for the list of authorized hosts, a new RR type 116 is defined with the mnemonic ALLOC. More than one ALLOC RR MAY 117 exist in an RRset; the RRset will contain the complete list of 118 authorized hosts for an address. ALLOC RRs TTL values SHOULD be 119 consistent with zone TTL values, as dynamic configuration 120 servers SHOULD maintain consistent identities. The class used 121 by the ALLOC RR MUST be IN. 123 2.1 Record Format: 125 NAME The domain name of the IP address the allocation is 126 associated with. 127 TYPE ALLOC 128 CLASS IN 129 TTL (as appropriate) 130 RdLen (variable) 131 RDATA 132 Field Name Data Type Notes 133 ----------------- ------------ --------------- 134 Authorized Name domain-name The FQDN of the 135 authorized server. 137 2.2 Example 139 NAME 1.0.0.127.IN-ADDR.ARPA. 140 TYPE ALLOC 141 CLASS IN 142 TTL 86400 143 RdLen 25 145 RDATA 146 Field Name Contents 147 ------------------- ---------------------- 148 Authorized Name DHCP-V4.ARBITRARY.ISP.XX. 150 3. Verifying a Dynamic Configuration Server 152 Without an in-band mechanism to retrieve DNS data, the DHCP client 153 sends a DHCPREQUEST, and deliver a DHCPDECLINE normally. On 154 reception of DHCPACK, the DHCP client MAY adopt the 155 configuration and begin verification. 157 3.1 Verification of Server Authority 159 When a dynamic configuration server provides configuration 160 information, it MUST sign this information using a DNSSEC 161 private key with protocol number TBD. Along with the signature, 162 the server MUST provide a key identifier, which, in the case of 163 DNSSEC key use, will be the FQDN of the server. When a client 164 receives the configuration information, it MUST retrieve the ALLOC 165 RR associated with the reverse name lookup form of its IP address, 166 and verify this information using DNSSEC. For example, 167 1.0.0.127.IN-ADDR.ARPA. If the server's FQDN is not among the 168 authenticated sources listed, the operation MUST fail. 170 3.2 Verification of Server signature 172 Upon success it MUST retrieve the public keyset for the dynamic 173 configuration server FQDN, as well as verify it using DNSSEC. 174 If the key (with appropriate protocol number) is not present or 175 it cannot retrieve the key in a secure manner, the operation 176 MUST fail. 178 Finally, the client MUST use the public key retrieved to verify the 179 signed configuration packet. In the event that multiple keys 180 match both the FQDN and protocol number, verification MUST be 181 attempted with each key until either the operation succeeds, or 182 there are no more keys. If none of the provided keys validates 183 the configuration information, the operation fails. 185 3.3 Failure Behavior 187 Two types of failure may occur during DNSSEC verification: an 188 operational failure and security failure. The operational 189 failure might occur in the form of timeouts in DNS or DHCP. If an 190 operation error occurs, configuration MUST be rolled back, and the 191 DHCPDISCOVER process MAY be restarted. Any verified DNSSEC data 192 (where verification is assured through use of the root key) MAY be 193 preserved, but any un-verified DNSSEC data MUST be discarded. 194 Particular care should be taken to assure that DNS cache data is 195 restored to its original state if needed. 197 A security error may occur in the form of a failure to locate 198 valid DNSSEC entries supporting the chain of zone delegation, or 199 failure to authoritatively locate ALLOC records. If the ALLOC ALLOC 200 records do not list the DHCP server trying to allocate the IP 201 address, or the DNSSEC key for the DHCP server cannot verify the 202 packets delivered. If this occurs, similar preservation and 203 removal of DNSSEC data as operational failure behavior MUST 204 occur. A security notice indicating a security event MUST be 205 provided to the user. Following the removal of DHCP 206 configuration information, the DHCPDISCOVER process MAY be 207 restarted. 209 4. Practical Protocol Implementation Information 211 In DHCP there is no in-band mechanism for transporting DNSSEC 212 information, as size limits on packets are not sufficient to contain 213 the number of DNSSEC records necessary to perform all the steps 214 above. DHCP SHOULD, however, provide DNS server contact 215 information. If a signature is detected, and security 216 verification is desired, the client MAY adopt temporarily the 217 identity defined in the DHCP server response, but only for the 218 purposes of DNSSEC verification. Other network communications 219 MUST NOT take place beyond that required by DHCP and DNSSEC 220 verification of the DHCP message. This should minimize the 221 impact of adopting an address already in use on the network. 223 Where configuration systems provide additional carrier capacity, or 224 provide temporary communication facilities, these features COULD be 225 used to retrieve DNSSEC information. A configuration server 226 SHOULD be able to "prime" the clients DNSSEC cache with all 227 information it will need to perform the verification steps, 228 meaning that the client will not have to perform any normal DNS 229 communication, reducing the chances of network conflict, denial 230 of service, or time-expensive lookup procedures. This mechanism 231 SHOULD be used as long as DNSSEC information used in the 232 verification is not retained in the event that the verification 233 fails. Otherwise, an attacker could poison DNSSEC information in 234 the cache, disrupting future verification of a valid DHCP 235 server. 237 4.1 DNSSEC Data Requirements 239 To perform a verification, a client will need a complete chain of 240 delegation, key, and signature information to both its IN-ADDR.ARPA. 241 RRset and the KEY information of the FQDN of the server 242 providing the DHCP information, as well as appropriate glue 243 records and the ALLOC RRs. 245 5. Storage Considerations 247 This record should be stored normally with records in its zone. In 248 text-format, it should be written as with the NS RR type. It is 249 expected that ALLOC RRs will often be stored with a wildcard 250 name so as to cover an entire reverse name lookup zone. 252 6. Security Considerations 254 The DNSSEC verification RR and procedure will provide verification 255 that the IN-ADDR.ARPA. zone maintainer believes the DHCP server 256 is valid, but it is conceivable that this is not the case. The 257 DNSSEC delegation security is assumed to be trusted, and any 258 DHCP server with the DNSSEC key will be unconditionally 259 believed. 261 6.1 Network Routing 263 A client MUST be able to communicate with the DHCP server to perform 264 DHCP, and MUST be able to retrieve DNS information. All other 265 communications SHOULD be restricted to prevent interference with 266 other hosts, or unauthorized access to the network. 268 6.2 Client Network Use 270 Clients MUST NOT trust the network for any communications but DHCP 271 and DNSSEC. Identities MAY be assumed to verify configuration 272 information, but use of the identity SHOULD be severely 273 restricted to minimize network interruption for other hosts if 274 the information is incorrect. 276 6.3 Timing Issues 278 Digital signatures in DHCP and DNSSEC have expiry time information 279 in them. Clients MUST NOT rely on any network-based timing 280 source unless the network configuration has been validated. 281 Otherwise, the client clock could be set back to replay old 282 settings or follow an outdated trust hierarchy. 284 6. References 286 [RFC1034] P. Mockapetris, "Domain Names - Concepts and 287 Facilities," RFC 1034, ISI, November 1987. 289 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 290 Specification," RFC 1034, ISI, November 1987. 292 [RFC2065] D. Eastlake, C. Kaufman, "Domain System Security 293 Extensions," RFC 2065, CyberCash & Irix, January 1997. 295 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol," 296 RFC 2131, Bucknell University, April 1997. 298 [DHCPSEC] O. Gudmundsson, "Security Architecture for DHCP," 299 draft-ietf-dhc-security-arch-01.txt, July 1997. 301 [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key 302 Transaction Signatures for DNS", 303 draft-ietf-dnsind-tsig-02.txt, ISC, TIS, CyberCash, 304 July 1997. 306 7. Author's Addresses 308 Robert Watson Olafur Gudmundsson 309 7100 Marbury Rd. Trusted Information Systems 310 Bethesda, MD 20817 3060 Washington Road 311 +1 301 229 2822 Glenwood, MD 21738 312 +1 301 854 6889