Dynamic Host Configuration WG                         Olafur Gudmundsson
INTERNET DRAFT                               Trusted Information Systems
<draft-ietf-dhc-security-arch-01.txt>                     July 30, 1997


                   Security Architecture for DHCP
                   <draft-ietf-dhc-security-arch-01.txt>


   Status of this Memo

   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 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Abstract

   This document addresses the general security requirements of both
   DHCPv4 and DHCPv6. This document lists security requirements and
   proposes a security model, which meets scaling requirements,
   security requirements and efficiency requirements.

   The proposed security model uses public key cryptography and a
   proposed trusted key distribution mechanism to authenticate clients
   and servers. Once clients have authenticated themself less expensive
   mechanishms can be used to protect subsequent communication.  The
   security model also addresses securing relay agents and server to
   server protocols.


1.  DHCP security requirements

   One of the problems of designing a security model for DHCP[DHCP] is
   the wide variety in use and preconditions that different sites/
   clients have. The fact that sites deploy redundant servers and
   the lack of a server to server protocol further complicates
   things[Server,Intserver].

1.1. Authentication, confidentiality, data integrity

   RFC-1825[RFC1825] contains a great description of these terms and
   their uses. Authentication is the process of establishing the
   identity of some entity.  Once identity has been authenticated,
   that identity can be used for access control, accounting etc.

Expires January 30, 1998                                        [Page 1]


Internet Draft                                             July 30, 1997

   There are number of authentication technologies available.

   Public key cryptography is a powerful tool that relies on complex
   mathematical operations to provide information that only the holder
   of the private key could have generated. This technology can be
   used for all the functions named in the title of this section.

   Shared secret authentication is the process of digesting the data
   transmitted and obfuscating the digest by applying a transformation
   by a key that is only used by the two entities. This technology
   can be used to provide both authentication and data integrity.
   Each pair can share multiple shared secrets, it is important
   that each secret have an identifier attached to it.

   Confidentiality can be accomplished by encrypting the data contents
   of the outgoing packet. Shared secrets can be used as keys for
   symmetric encryption.

1.2. Shared secrets

   Shared secrets are between two entities; there is NEVER a need to
   share these secrets with other entities. The hosts storing the
   secrets MUST protect the secrets as well as possible.


1.3 Terminology and DHCP v6 considerations

   This document uses DHCPv4 terminology as it is more familiar than
   the new DHCPv6[DHCPv6] terminology. When this document talks
   about DISCOVER messages the same will apply to DHCP v6 Solicit
   Message.  No changes are needed in the protocol section 6 to
   support DHCPv6; some currently proposed DHCPv6[DHCPv6EXT]
   security options need to be modified.

   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. Proposed DHCP security requirements

   The proposed requirements can be summarized in the following rules.

  - Initial Client/Server Authentication

        1.  Server MUST authenticate client identity.

        2.  Client SHOULD authenticate the server identity as an
            authorized server.



  - Initial Relay Agent/Server Authentication


Expires January 30, 1998                                        [Page 2]


Internet Draft                                             July 30, 1997

        3.  Server MUST authenticate relay agent identity as an
            authorized relay agent.

        4.  Relay Agent MUST authenticate server identity as an
            authorized server.

HAND JUSTIFY
  - Successive Client to Server and Relay Agent to Server Communication

        5.  Client and Server MUST have agred on security model for
            protecting future communication.

  - Server/Relay agent advertisements

        6. Advertisements MUST be verifiable by all recipients.

  - Server/Server communication

         7. All communication MUST be protected for data integrity.
            Servers MAY request that communication be encrypted.

   DHCP security cannot be accomplished in a vacuum; as DHCP is not a
   general purpose communication protocol. Fortunately there are
   available (or soon will be) protocols that DHCP can take advantage
   of. First and foremost DNSSEC[RFC2065] or some other key
   distribution mechanism must be available. IPSEC[RFC1825,IPSEC]
   will be able to handle requirement 5. It is not clear if IPSEC
   for IPv6, in some cases using local link addresses, can address
   requirement 1-4. In the case of IPv4 DHCP MUST perform the
   initial authentication.

2.1. DHCP Identity

   In order to secure DHCP all clients MUST have an identity, this
   identity can possibly be one of the following: host name, user
   identity, account code. The "prime" identity MUST have a public key
   stored in the key distribution mechanism. The client MUST know its
   identity before contacting the server.  Each client MUST have access
   to the correct private key before contacting the DHCP server.

   If the identity selected for a host is its host name and the key
   distribution mechanism is DNS, then the public key used to
   authenticate the host is stored under the host name in its home
   zone. The private key needs to be stored in the computer at all
   times. If the identity selected is the user then the key is stored
   under the user name in DNS (e.g.: ogud.tis.com for me), and the user
   needs to load the computer with the private key before the host
   can contact the server.  If the identity of the host is just
   there to uniquely identify the host, the host still needs a
   private key.



2.2. DHCP communication protection


Expires January 30, 1998                                        [Page 3]


Internet Draft                                             July 30, 1997

   DHCP is a protocol that carries publicly known information, thus
   there is limited need for confidentiality. DHCP requires data
   integrity protection for communication. The option to allow DHCP
   servers/clients to request confidentiality SHOULD be part of any
   security architecture.

2.3. Policy issues.

   This document does not address access control issues as that is a
   policy issue for each site. Effective access control depends on
   correct authentication, thus this work will make access control
   simpler.  This document does not address the issue of protecting the
   private key on either server, agent or client.

2.4 Security threats to DHCP

2.4.1 Attacks against servers

   There are many possible attacks possible against servers, including
   denial of service by exhausting the servers allocated address space.
   Another denial of service attack is to overload the server causing
   it not to respond to clients.

   Once servers start updating DNS and other directory services, DHCP
   servers can be spoofed to register incorrect information in those
   services.

   Another possible attack is to gain unauthorized access to some
   resources, such as network access.

2.4.2 Attacks against clients

   This is a less known problem, but should not be ignored.  Fake
   servers can provide clients with partially correct information
   that allows the attacker to route traffic through certain host
   where critical information can be collected.  This becomes
   important to detect and prevent when encrypted traffic is
   allowed to pass through firewalls.

   Clients can be configured with bogus data, so that they will assume
   that the network is down. In some cases it is hard to get a
   client to reconfigure itself. Clients can also be configured
   with addresses of other clients, causing address conflicts.

   The bright side of this problem is that it is not that hard to
   detect fake servers by monitoring the network for DHCP traffic.


2.5. Complications in implementing the security models

   A Client that issues DISCOVER message does not have any IP address
   that works outside the local network, and may not even work on
   the local network.  This prevents the clients from checking with
   outside information sources. Servers on the other hand are fully

Expires January 30, 1998                                        [Page 4]


Internet Draft                                             July 30, 1997

   configured and can use any information sources accessible.

   Clients will not wait long for OFFER message, some security checks
   may take longer than the DHCP retransmission timeout. If DHCP
   servers had an option to inform clients that DISCOVER messages
   are being worked on and client should expect an answer in short
   order, then this problem would be solved.

   Some DHCP servers do not have CPU cycles to spare to do security
   checks. This is a bogus argument, since inexpensive powerful
   computers are available and sites should upgrade if security is
   of concern.



3. DHCP Security components

3.1 Authentication services

   In order for DHCP servers to be able to determine if a client
   request should be serviced it is essential for the server to be
   able to establish the client's identity. There are two kinds of
   identities that are possible, local mutually agreed upon
   identities and global identities.

   Local identity is sufficient if the client will only be configured
   from a small set of servers, and if there are no expectations
   that the client will migrate to another location. This is an
   acceptable solution for a site where all computers are
   stationary but are configured from DHCP for administrative
   reasons. Solutions of this kind have certain scaling problems.

   Global identity on the other hand is needed when a client can
   connect to multiple servers and it provides some of its
   identity.

   An example of local identity is a name or number that is
   configured in the client and server. This could be the name of the
   client on the local network.  A good example of global identity
   is a DNS domain name.

3.2 Time service

   To prevent replay attacks, DHCP messages must contain time
   information that clients and servers check and act upon. Clock
   synchronization service can be provided by an outside
   entity[RFC1305] once a client is configured, but bounds must be
   placed on acceptable skew while a client is off line or migrates
   between locations. Clients SHOULD not trust time information
   from servers until after servers have been validated as such.
   Clients should always assume that the network is insecure.

3.3 Data confidentiality


Expires January 30, 1998                                        [Page 5]


Internet Draft                                             July 30, 1997

   This is not desired service at this point, but it can be added at a
   later point for all communication except DISCOVER and possibly OFFER
   and REQUEST. All subsequent communication can be encrypted.

3.4 Possible security models for DHCP

   This section will present a few possible security models and the
   reasons why each one may be useful. This section IS NOT an
   advocacy for any of the descibed models

3.4.1 The "No security" model

   This is the current situation. The motivation for not changing
   anything is that security is hard. Considering that DHCP for IPv4 is
   a hack built on an older hack (BOOTP), there is not enough
   flexibility in the protocol to add security.

   A smart client attached to a broadcast network can learn everything
   it needs to know to configure itself by listening to network
   traffic. The client can either monitor DHCP traffic and/or all
   network traffic to find gateways, servers and unused addresses.
   There is no protection against this.

   DHCPv6 can on the other hand be extended and modified to fit any
   security model selected. Sites will migrate to IPv6 soon, and
   the ones that do not deserve what they get.

   In this model DHCP clients will be able to do harm and be harmed
   by bogus servers. This model is not acceptable when DHCP servers
   perform update operations on a client's behalf.  Sites MAY
   select this model but this is strongly discouraged.

3.4.2 The "Simple" model

   A DHCP client is configured with a token that allows it to
   authenticate itself to the servers in the DHCP DISCOVER message.
   If servers can authenticate the token and the client associated
   with the token is allowed to communicate with the server the
   server will reply with OFFER message.

   In this model servers will know with which  client they are dealing,
   and that should be sufficient protection against most of the
   attacks against the servers. If a client is able to authenticate
   the server response, the client might be protected against bad
   servers.

   With minor extensions to DHCP, all subsequent communication can be
   protected.




3.4.3 The "Comprehensive" Model


Expires January 30, 1998                                        [Page 6]


Internet Draft                                             July 30, 1997

   In this model DHCP servers and clients have the ability to
   authenticate each other. The requirement here is that clients must
   be able to authenticate the server without any communication as
   they can not trust the information from the server. This model
   also must prevent replay attacks.

   This model protects all traffic between clients and servers, making
   it impossible to stage any attacks other than denial of service
   attacks due to CPU overload of servers.


4. Client Authentication:

   Initial authentication is the most important step. Once server and
   client have established each other's identity the remaining
   problems can solved.

   The problem of initial client authentication cannot be solved by
   IPSEC, as the client does not have an IP identity when it requests
   service for the first time from the server.  Once the client has
   been configured it can enter IPSEC security associations with
   other DHCP servers during the lifetime of the IP address lease.

4.1 Types of DHCP clients and their identification needs.

   In DHCP there are two types of clients: clients that request some of
   their net identity from DHCP, and clients that request all of their
   net identity  from DHCP. From a security point of view, the
   second type of client is no different, because these clients
   must have some identity (for example MAC address) that can be
   used to uniquely identify them. Previous DHCP security
   proposals[DHCAUTH] have suggested the use of shared secrets and
   passwords to identify clients.  It is also possible to use some
   form of challenge/response system to identify clients. These
   approaches have limited scaling ability and require a server to
   server protocol. But in many environments these weaker
   authentication mechanisms are adequate.

   The most general case is the identification of a computer that
   connects to a world wide ISP network and expects the same identity
   regardless of location. In this case it is unlikely that the same
   DHCP server serves both India and Iceland. A network of this
   kind can have a collaborative agreement between a number of
   different ISPs, with multiple administrative domains. It is not
   reasonable/scalable that all DHCP servers in this network know
   shared secrets, or passwords for all computers that are allowed
   to connect.  From a security standpoint it is a bad practice to
   distribute shared secrets or passwords to many places.

4.2. Motivation for single strong authentication schema.

   It is better to mandate ONE strong authentication protocol for all
   DHCP interaction, rather than allow for multiple ones and allow
   sites to choose the wrong one. The protocol below uses strong

Expires January 30, 1998                                        [Page 7]


Internet Draft                                             July 30, 1997

   authentication with public key signatures and encryption. The
   security of the protocol depends on the difficulty in breaking
   the private keys used. The site security depends on the sites
   protecting the private keys. By mandating one protocol at this
   point, we also eliminate the need for negotiating what
   authentication protocol to use. At this point, the public key
   algorithm is MUST be RSA.


4.3 Motivation for global DNS identities for DHCP clients

   Once the global identity is registered with an information service,
   this identity is available within the limits of the information
   service.  DNS is the most common information service used by
   computers.


   DNSSEC[RFC2065] strengthens DNS[RFC1035] against information
   corruption and provides distribution of public keys. If every host
   that is configured by DHCP has a public key stored in DNS then
   servers can verify digital signatures generated by that key.
   Once clients are configured it is possible for client to verify
   that the server it was configured by is a good DHCP server. In
   order to do this, either SRV[SRV] records or ALLOC[DHCPVERSERV]
   DNS record must list the DHCP servers for each domain.

   IPSEC can be preconfigured with SPI's but there is no definition for
   the format of the 'destination address'. If it is DNS format, DHCP
   entities MAY enter IPSEC relationship without a key exchange once
   client has received DHCP ACK message.

5. DHCP security options and their processing

5.1 DNS Identity option

   This option allows the DHCP entities to advertise their own public
   keys which are stored in DNS and DNSSEC provides secure key rerival
   mechanism.

        Field           value   size in bytes
        -------------   ------  -----------
        option          TBD    1
        length          0-255  1
        selector        0-64K  2
        name                   variable < 250

   The name specified in this option does not have to be the same name
   that the client is requesting/using.





5.2 Signature option

Expires January 30, 1998                                        [Page 8]


Internet Draft                                             July 30, 1997


   This is an option that carries any type of signature that can be
   specified.

        Field           value   size in bytes
        -------------   ------  -----------
        option          TBD     1
        length          0-255   1
        algorithm       1-253   1
        ID              0-2^16  2
        current time    0-2^32  4
        signature data  binary  variable < 246

   The following algorithms are defined and must be supported by all
   implementations.

        0               No signature data
        1               RSA/MD5 as specified in PKCS1[NETSEC], this is
                        identical to algorithm 1 in DNSSEC.

        100             HMAC-MD5 as specified in RFC2104[RFC2014]

   The ID is a 16 bit number that is identical to the key indentifier
   in the DNSSEC SIG record. This identifier is used to select a
   key from the key set of the name. If there are multiple keys in
   the key set that match this ID and can be used for DHCP and are
   the same size, the verifier must be ready to try all of the keys
   until verification succeeds.

   The current time value states at what time the signature is
   generated, in Universal Time. DHCP entity SHOULD accept signatures
   that are within 60 seconds of local time. If the signature is not
   within these bounds the whole packet should be rejected.

   The size of the signature data field depends on the algorithm used
   and for some algorithms, the key size. MD5 digests are 16 bytes.
   RSA signatures are always the same size as the modulus of the
   key. Signature data can never exceed 246 bytes, this restricts
   the key sizes used to about 1968 bits.

   The data covered by signatures is defined in section 5.3.1.  The
   Signature option MUST be the LAST option in the DHCP packet, adding
   a Signature option MUST NOT result in too large of a packet,
   other options MUST be removed to make space for the signature
   option.

   There are special considerations for Relay agents. A Relay Agent
   that adds a relay agent option(s) to a signed DHCP packet MUST
   add a Signature option after its option(s) and its signature
   MUST cover the whole outgoing packet.   If the incoming
   signature is addressed to this Relay Agent, the Relay Agent MUST
   remove that signature from the outgoing packet before adding its
   option(s) to the packet. If the incoming signature is a digital
   signature (alg=1) it MUST be retained.

Expires January 30, 1998                                        [Page 9]

Internet Draft                                             July 30, 1997


5.3.1 Data covered by signature option

   The whole outgoing DHCP packet is covered, including the signature
   option.

   For DISCOVER/SOLICIT the signature is calculated over

        Modified outgoing packet

   For all other messages the signature is calculated over

        digest of last valid incoming packet | Modified outgoing packet

   The modified outgoing packet is the whole DHCP packet with following
   differences:

        'giaddr' and 'hops' fields must be set to all zero.
        All bytes in the signature data must be set 0xa6.

   The digest of the last incoming packet from the other entity is to
   associate the outgoing packet to the request or last answer.

5.3 Wait option

   This option allows the server to inform the client that it is
   currently validating the clients identity and request that the
   client wait the specified time before retransmitting the query.

        Field           value   size in bytes
        -------------   ------  -----------
        option          TBD     1
        length          3       1
        seconds         1-6     1

   This option is to throttle back security aware clients while server
   is authenticating the clients identity. The client MUST ignore
   this option if it has received 2 previous ones from same server
   for the same message.


6. "Simple" DHCP authentication protocol

   This protocol is along the lines of the simple model described in
   section 3.4.2. The foundation that this protocol offers can be used
   to build a comprehensive protocol.

   This protocol depends on a reliable certified public key
   distribution mechanism like DNSSEC[DNSSEC]. Each client supplies
   its identity in the initial DISCOVER message. This identity
   indicates where the associated public key is stored. For DNS the
   identity is the FQDN (Fully Qualified Domain Name), accompanied
   by the key algorithm number and public key footprint. For other
   key distribution mechanisms there must be enough information to

Expires January 30, 1998                                        [Page10]
Internet Draft                                             July 30, 1997

   retrieve the key from that source.

   To successfully validate a server public key, clients must be
   configured with the root key(s) for the key distribution
   certification tree.

   The protocols below make use of currently undefined options, these
   options must be specified before this proposal can be adopted.


6.1 DHCP authentication protocol overview

   In the following discussion, DHCP options not important to the
   overall schema are not included.

6.1.1 Client: DISCOVER message MUST include

        IDENTITY option (contains identity type, name, unique selector)
        Signature option (alg=1) signed by public key in IDENTITY option.


6.1.2 Server: DHCP-OFFER message

   If server is able to validate DISCOVER message from a client it
   shares a secret with it MUST include following options.

        IDENTITY option
        Signature option (alg=100)

   If the client is able to verify this message, it has authenticated
   the server and the authentication protocol is complete. Future
   communication can be protected by this secret.

   If the server is able to validate DISCOVER message from a client
   that it does not share a secret with, the following options MUST
   be included.

        IDENTITY option
        Signature option (alg=1)

   If the server needs more time to complete authentication it can send
   back

        WAIT option
        Signature option 0

   If the server refuses to offer service, as the time in request is
   out of bounds, the server sends back OFFER which MUST contain
   only the following options: (EMPTY OFFER).

        IDENTITY option
        Signature option

   If server is unable to authenticate the identity of the client, the

Expires January 30, 1998                                        [Page11]
Internet Draft                                             July 30, 1997

   server MUST ignore the client messages. The server SHOULD log the
   event and CAN ignore requests from the same hardware address for a
   fixed time.

6.1.3 Client DHCP-REQUEST processing

   If the server has accepted the client's identity, the client can now
   send the REQUEST message, and this message MUST be signed by its
   public key in order for other servers to verify that their
   offers were declined. The following options MUST be present:

        IDENTITY
        Security option (alg=1)


6.2 Future communication

   Once a client that does not share a secret with the server selected
   has been configured, it can optionally authenticate the server as
   specified in[DHCPVERSERV].  All future communiction between the
   client and the server MUST contain data protection. It can also
   attempt to exchange secrets with the server via an optional
   protocol extension "To Be Determined". If IPSEC is available it
   CAN be used to protect future communication until the client is
   renumbered.  The client and server can also elect to use RSA
   signatures on all communication.

6.3 Computational complexity of Simple Authentication Protocol

   This protocol places most of the cost of the expensive public key
   operations on the client. Servers need to generate signatures on all
   messages to clients that do not share secrets with them.

   The cost of verifying the public keys of the client can be to a
   large extent offloaded to the DNSSEC server if a DNS transaction
   signature mechanism[RFC2065,TSIG] is used to protect the
   communication.

6.4 Client security requirements

   Security enabled DHCP clients MUST be able to store their identity
   and private key between reboots. These same clients SHOULD have
   a clock that keeps reasonable good time.  The client SHOULD be
   able to store multiple Server Identities and Shared secrets
   between reboots.   Clients MUST be able to perform the following
   security operations:  RSA/MD5 digital signatures and HMAC-MD5.

6.5 Server security requirements

   Security enabled DHCP servers MUST be able to store identities and
   shared secrets with a large number of clients. Servers MUST be able
   to perform RSA/MD5 and HMAC-MD5 operations. Servers MUST be
   configured with either secure DNS resolver, or other form of
   trusted communication with DNSSEC server.

Expires January 30, 1998                                        [Page12]
Internet Draft                                             July 30, 1997


7. Security considerations

   This document addresses how to add security features to the
   unsecured DHCP protocol.

7. References

     [DHCP]  R. Droms, "Dynamic Host Configuration Protocol", RFC
     2131, Bucknell University, April 1997.

     [DHCAUTH] R. Droms,  "Authentication for DHCP Messages",
     Internet Draft <draft-ietf-dhc-authentication-03.txt> November
     1996

     [DHCPv6] J. Bound, C. Perkins,
     "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     Internet Draft  <draft-ietf-dhc-dhcpv6-10.txt> May 1997

     [DHCPv6EXT] C. Perkins, "Extensions for DHCPv6", Internet Draft
     <draft-ietf-dhc-v6exts-06.txt> May 1997

     [DHCPVERSERV] R. Watson, O. Gudmundsson,
     "DHCP Server verification by client via DNSSEC",
     <draft-watson-dhc-serv-ver-00.txt> July 1997.

     [HMAC]   H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
     Hashing for Message Authentication", RFC 2104, February 1997

     [Intserver] R. Droms, K. Kinnear, "An Inter-server Protocol for
     DHCP", Internet Draft <draft-ietf-dhc-interserver-alt-00.txt>,
     April 1997

     [Server] R. Droms, R. Cole, "An Inter-server Protocol for
     DHCP", Internet Draft <draft-ietf-dhc-interserver-01.txt>
     March 1997.

     [IPSEC] R. Atkinson, "Security Architecture for the Internet
     Protocol", Internet Draft <draft-ietf-ipsec-arch-sec-01.txt>,
     November 1996.

     [RFC1035] P. Mockapetris, "Domain Names - Implementation and
      Specification,"  RFC 1034, ISI, November 1987.

     [RFC1305] Mills, D., "Network Time Protocol (v3)", RFC 1305,
     March 1992.

     [RFC1825] R. Atkinson, "Security Architecture for the Internet
     Protocol", RFC 1825, September 1995.

     [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security
     Extensions", RFC 2065, January 1997.

     [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the

Expires January 30, 1998                                        [Page13]
Internet Draft                                             July 30, 1997

     location of services (DNS SRV)", RFC 2052, October 1996.

     [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP
     Vendor Extensions", RFC 2132, March 1997.

     [NETSEC] C. Kaufman, R. Perlman, M. Speniner, "Network
     Security: PRIVATE Communications in a PUBLIC World", Prentice
     Hall 1995.


9. Author address

     Olafur Gudmundsson
     Trusted Information System
     3060 Washington Road
     Glenwood, MD 21738
     +1 301 854 5794
     <ogud@tis.com>





































Expires January 30, 1998                                        [Page14]