INTERNET DRAFT Robert Watson (TIS) Olafur Gudmundsson (TIS) July 30, 1997 DHCP Server Verification by Client Via DNSSEC Status of this Document This draft, file name draft-watson-dhc-serv-verify-00.txt is intended to be become an Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the authors. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Abstract The document defines a mechanism to allow a DHCP client to verify the authenticity of a DHCP server configuration offer using DNSSEC. Currently DHCP clients have no way to assess which of DHCP OFFERS are from valid DHCP servers, and which are not. Malicious DHCP servers can cause various network problems for unsuspecting clients. In order to support DHCP server authorization a new DNS Resource Record type (ALLOC) is added. Using the ALLOC record in combination with the servers KEY record the client can authoritatively assess if the server is authorized. 1. Introduction The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated hierarchal distributed database system that provides information fundamental to Internet operations, such as name <=> address translation and mail handling information. DNS has recently been extended [RFC2065] to provide for data origin authentication, public key distribution, and query and transaction authentication, all based on public key cryptography and Expires January 30, 1998 [Page 1] Internet Draft July 30, 1997 public key based digital signatures. The Dynamic Host Configuration Protocol (DHCP) [DHCP] can provide the essential configuration to a new host such that it can interact with the network. This usually includes any TCP/IP parameters needed to establish communication as well as network server information, usually including DHCP server, DNS servers, WINS server, TFTP server, and others. DHCP servers typically restrict address allocation based on the identity of the requesting entity, and DHCP security will address this authentication. However, there is no easy way for a client to verify that the server it is communicating with is a valid DHCP server without preconfigured information about which servers are valid. If multiple server requests are received, it is conceivable that one may be the result of a malicious entity trying to cause network problems by misconfiguring hosts. A shared secret with known DHCP servers is reasonable, but for mobile IP hosts connecting to multiple service providers, this is not feasible. Without such verification, serious security problems can entail. An unauthorized server could define routing and DNS information maliciously, making all client communications pass through the server. A DHCP signature option for authentication has been defined [DHCPSEC]. 1.1 DNS Considerations With DNS Security, all hosts will be preconfigured with a root DNS key, or a Transaction Signature (TSIG) [TSIG] shared secret for communication with a DNS server. For hosts with a root key, it is possible to verify the server's authenticity in offering an IP address. Associated with all verifiable addresses will be a list of authorized FQDNs for hosts. Once some type of preliminary communication is established (either by trusting the DHCP server for some minimal level, or by an undefined post-DHCP or in-DHCP protocol), DNSSEC can be used to extract the hostname and key of the server, if they are listed as an authorized server. Thus, by using the root key and DNSSEC, a chain of authority can be employed to verify that the DHCP server authorized the update. The identity of the DHCP server can be verified by checking the digital signature to the DHCPOFFER packet using a DNSSEC private key of the host, which can then be verified using the DNSSEC public key retrieved using the allocation resource record. The allocation record is associated with the reverse lookup record for an IP address in the IN-ADDR.ARPA. domain, and when retrieved, returns a list of FQDNs that are acceptable. Both the construction of ALLOC RRs and their use in authenticating IP address allocation are discussed in this document. Expires January 30, 1998 [Page 2] Internet Draft July 30, 1997 1.2 Keywords Used 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. 2. IP Address Address Allocation Resource Record Format To provide storage for the list of authorized hosts, a new RR type is defined with the mnemonic ALLOC. More than one ALLOC RR MAY exist in an RRset; the RRset will contain the complete list of authorized hosts for an address. ALLOC RRs TTL values SHOULD be consistent with zone TTL values, as dynamic configuration servers SHOULD maintain consistent identities. The class used by the ALLOC RR MUST be IN. 2.1 Record Format: NAME The domain name of the IP address the allocation is associated with. TYPE ALLOC CLASS IN TTL (as appropriate) RdLen (variable) RDATA Field Name Data Type Notes ----------------- ------------ --------------- Authorized Name domain-name The FQDN of the authorized server. 2.2 Example NAME 1.0.0.127.IN-ADDR.ARPA. TYPE ALLOC CLASS IN TTL 86400 RdLen 25 RDATA Field Name Contents ------------------- ---------------------- Authorized Name DHCP-V4.ARBITRARY.ISP.XX. 3. Verifying a Dynamic Configuration Server Without an in-band mechanism to retrieve DNS data, the DHCP client sends a DHCPREQUEST, and deliver a DHCPDECLINE normally. On reception of DHCPACK, the DHCP client MAY adopt the configuration and begin verification. Expires January 30, 1998 [Page 3] Internet Draft July 30, 1997 3.1 Verification of Server Authority When a dynamic configuration server provides configuration information, it MUST sign this information using a DNSSEC private key with protocol number TBD. Along with the signature, the server MUST provide a key identifier, which, in the case of DNSSEC key use, will be the FQDN of the server. When a client receives the configuration information, it MUST retrieve the ALLOC RR associated with the reverse name lookup form of its IP address, and verify this information using DNSSEC. For example, 1.0.0.127.IN-ADDR.ARPA. If the server's FQDN is not among the authenticated sources listed, the operation MUST fail. 3.2 Verification of Server signature Upon success it MUST retrieve the public keyset for the dynamic configuration server FQDN, as well as verify it using DNSSEC. If the key (with appropriate protocol number) is not present or it cannot retrieve the key in a secure manner, the operation MUST fail. Finally, the client MUST use the public key retrieved to verify the signed configuration packet. In the event that multiple keys match both the FQDN and protocol number, verification MUST be attempted with each key until either the operation succeeds, or there are no more keys. If none of the provided keys validates the configuration information, the operation fails. 3.3 Failure Behavior Two types of failure may occur during DNSSEC verification: an operational failure and security failure. The operational failure might occur in the form of timeouts in DNS or DHCP. If an operation error occurs, configuration MUST be rolled back, and the DHCPDISCOVER process MAY be restarted. Any verified DNSSEC data (where verification is assured through use of the root key) MAY be preserved, but any un-verified DNSSEC data MUST be discarded. Particular care should be taken to assure that DNS cache data is restored to its original state if needed. A security error may occur in the form of a failure to locate valid DNSSEC entries supporting the chain of zone delegation, or failure to authoritatively locate ALLOC records. If the ALLOC ALLOC records do not list the DHCP server trying to allocate the IP address, or the DNSSEC key for the DHCP server cannot verify the packets delivered. If this occurs, similar preservation and removal of DNSSEC data as operational failure behavior MUST occur. A security notice indicating a security event MUST be provided to the user. Following the removal of DHCP configuration information, the DHCPDISCOVER process MAY be restarted. Expires January 30, 1998 [Page 4] Internet Draft July 30, 1997 4. Practical Protocol Implementation Information In DHCP there is no in-band mechanism for transporting DNSSEC information, as size limits on packets are not sufficient to contain the number of DNSSEC records necessary to perform all the steps above. DHCP SHOULD, however, provide DNS server contact information. If a signature is detected, and security verification is desired, the client MAY adopt temporarily the identity defined in the DHCP server response, but only for the purposes of DNSSEC verification. Other network communications MUST NOT take place beyond that required by DHCP and DNSSEC verification of the DHCP message. This should minimize the impact of adopting an address already in use on the network. Where configuration systems provide additional carrier capacity, or provide temporary communication facilities, these features COULD be used to retrieve DNSSEC information. A configuration server SHOULD be able to "prime" the clients DNSSEC cache with all information it will need to perform the verification steps, meaning that the client will not have to perform any normal DNS communication, reducing the chances of network conflict, denial of service, or time-expensive lookup procedures. This mechanism SHOULD be used as long as DNSSEC information used in the verification is not retained in the event that the verification fails. Otherwise, an attacker could poison DNSSEC information in the cache, disrupting future verification of a valid DHCP server. 4.1 DNSSEC Data Requirements To perform a verification, a client will need a complete chain of delegation, key, and signature information to both its IN-ADDR.ARPA. RRset and the KEY information of the FQDN of the server providing the DHCP information, as well as appropriate glue records and the ALLOC RRs. 5. Storage Considerations This record should be stored normally with records in its zone. In text-format, it should be written as with the NS RR type. It is expected that ALLOC RRs will often be stored with a wildcard name so as to cover an entire reverse name lookup zone. 6. Security Considerations The DNSSEC verification RR and procedure will provide verification that the IN-ADDR.ARPA. zone maintainer believes the DHCP server is valid, but it is conceivable that this is not the case. The DNSSEC delegation security is assumed to be trusted, and any DHCP server with the DNSSEC key will be unconditionally believed. Expires January 30, 1998 [Page 5] Internet Draft July 30, 1997 6.1 Network Routing A client MUST be able to communicate with the DHCP server to perform DHCP, and MUST be able to retrieve DNS information. All other communications SHOULD be restricted to prevent interference with other hosts, or unauthorized access to the network. 6.2 Client Network Use Clients MUST NOT trust the network for any communications but DHCP and DNSSEC. Identities MAY be assumed to verify configuration information, but use of the identity SHOULD be severely restricted to minimize network interruption for other hosts if the information is incorrect. 6.3 Timing Issues Digital signatures in DHCP and DNSSEC have expiry time information in them. Clients MUST NOT rely on any network-based timing source unless the network configuration has been validated. Otherwise, the client clock could be set back to replay old settings or follow an outdated trust hierarchy. 6. References [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification," RFC 1034, ISI, November 1987. [RFC2065] D. Eastlake, C. Kaufman, "Domain System Security Extensions," RFC 2065, CyberCash & Irix, January 1997. [RFC2131] R. Droms, "Dynamic Host Configuration Protocol," RFC 2131, Bucknell University, April 1997. [DHCPSEC] O. Gudmundsson, "Security Architecture for DHCP," draft-ietf-dhc-security-arch-01.txt, July 1997. [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS", draft-ietf-dnsind-tsig-02.txt, ISC, TIS, CyberCash, July 1997. 7. Author's Addresses Robert Watson Olafur Gudmundsson 7100 Marbury Rd. Trusted Information Systems Bethesda, MD 20817 3060 Washington Road +1 301 229 2822 Glenwood, MD 21738 +1 301 854 6889 Expires January 30, 1998 [Page 6]