Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_s_z/draft-watson-dhc-serv-verify-00.txt

Text File | 1997-08-02 | 15KB | 356 lines

INTERNET DRAFT                                       Robert Watson (TIS)
<draft-watson-dhc-serv-verify-00.txt>           Olafur Gudmundsson (TIS)
                                                           July 30, 1997

              DHCP Server Verification by Client Via DNSSEC
                 <draft-watson-dhc-serv-verify-00.txt>

   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
         [phone]                 Glenwood, MD 21738
         <[e-mail]>  [phone]


Expires January 30, 1998                                        [Page 6]