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

                   Security Architecture for DHCP
                      <draft-ietf-dhc-security-arch-00.txt>
                   <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 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 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 v4
   DHCPv4 and v6 versions of DHCP. DHCPv6. This document lists security requirements and
   proposes as 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. The authentication protocol Once clients have authenticated themself less expensive
   mechanishms can also
    exchange keying material for more efficiently protecting
    successive communication between client and server. be used to protect subsequent communication.  The
   security model also addresses securing relay agents. 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 sites/
   clients have. The fact that sites deploy redundant servers and
   the lack of a server to server protocol further complicates
    things, proposed server to server protocol is an Internet
    draft[Server]. This document assumes fair knowledge of DHCP.
   things[Server,Intserver].

1.1. What is authentication? 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 authenticated,
   that identity

Expires September 26, 1997                                     [Page  1] can be used for access control, accounting etc.. etc.

   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. For more
    background information see RFC-1825[RFC1825].

1.1. Requirements

    Throughout this document, the words that are used to define the
    significance of particular requirements are capitalized.  These
    words are:

          o "MUST" This word or technology can be
   used for all the adjective "REQUIRED" means that functions named in the item is an
    absolute requirement title of this specification.

          o "MUST NOT"

    This phrase means that the item section.

   Shared secret authentication is an absolute prohibition of
    this specification.

          o "SHOULD"

    This word or the adjective "RECOMMENDED" means that there may
    exist valid reasons in particular circumstances to ignore this
    item, but process of digesting the full implications should be understood data
   transmitted and obfuscating the
    case carefully weighed before choosing digest by applying a different course.

          o "SHOULD NOT"

    This phrase means transformation
   by a key that there may exist valid reasons in
    particular circumstances when the listed behavior is acceptable
    or even useful, but only used by the full implications should two entities. This technology
   can be understood 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 case carefully weighed before implementing any behavior
    described with this label.

          o "MAY"

    This word or data contents
   of the adjective "OPTIONAL" means that this item outgoing packet. Shared secrets can be used as keys for
   symmetric encryption.

1.2. Shared secrets

   Shared secrets are between two entities; there is
    truly optional.  One vendor may choose NEVER a need to include
   share these secrets with other entities. The hosts storing the item
    because a particular marketplace requires it or because
   secrets MUST protect the secrets as well as possible.

1.3 Terminology and DHCP v6 considerations

   This document uses DHCPv4 terminology as it
    enhances is more familiar than
   the product, for example; another vendor may omit new DHCPv6[DHCPv6] terminology. When this document talks
   about DISCOVER messages the same item.

Expires September 26, 1997                                     [Page  2]

2. Proposed DHCP 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 server.

  - Initial Relay Agent/Server Authentication
 	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 agree 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; fortunately 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[DNSSEC] DNSSEC[RFC2065] or some other KEY 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 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.

    For example if

   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

Expires September 26, 1997                                     [Page  3] the host is just
   there to uniquely identify the host, the host still needs a
   private key.

2.2. DHCP communication protection
   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, but effective 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.

3. Client Authentication:

    One

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 goals servers allocated address space.
   Another denial of this document service attack is to convince overload the working
    group that achieving initial authentication is the most
    important step. Once server causing
   it not to respond to clients.

   Once servers start updating DNS and client have established each
    other's identity the remaining problems other directory services, DHCP
   servers can easily be solved.

    The problem of initial client authentication cannot be solved by
    IPSEC, spoofed to register incorrect information in those
   services.

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

2.4.2 Attacks against clients

   This is a less known problem, but should not have an IP identity when it
    requests service for the first time from server.  Once client
    has been configured it be ignored.  Fake
   servers can enter IPSEC security associations provide clients with other DHCP servers during the lifetime of partially correct information
   that allows the IP address
    lease.

3.1 	Types of DHCP clients attacker to route traffic through certain host
   where critical information can be collected.  This becomes
   important to detect and their identification needs.

    To DHCP there are two kinds of clients. prevent when encrypted traffic is
   allowed to pass through firewalls.

   Clients can be configured with bogus data, so that request
    some of their net identity, and clients they will assume
   that request ALL of
    their net identity from DHCP. From a security point of view, the
    second type of client network is no different, because these clients
    must have down. In 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 cases it is also possible to use some
    kind of challenge/response system hard to identify clients. These
    approaches have limited scaling ability and require get a server
   client to
    server protocol. But in many environments these weaker
    authentication mechanisms are adequate.

    The most general case is the identification reconfigure itself. Clients can also be configured
   with addresses of a computer that
    connects to a world wide ISP network and expects the same
    identity regardless other clients, causing address conflicts.

   The bright side of location. In this case it problem is unlikely that the same DHCP server serves both India and Iceland. A
    network of this kind can have a collaborative agreement between
    number of different ISPs, with multiple administrative domains.
    It it is not reasonable/scalable that all DHCP hard to
   detect fake servers in this by monitoring the network know shared secrets, or passwords for all computers that
    are allowed to connect.  From a DHCP traffic.

2.5. Complications in implementing the security standpoint it is a bad
    practice to distribute shared secrets or passwords to many
    places.

3.2. Motivation for single strong authentication schema.

Expires September 26, 1997                                     [Page  4]
    The author feels models

   A Client that it is better to mandate ONE strong
    authentication protocol for all DHCP interaction, rather than
    allow for multiple ones and allow sites to choose issues DISCOVER message does not have any IP address
   that works outside the wrong one.
    The protocol below is a strong authentication using public key
    signatures local network, and encryption. The security of the protocol depends may not even work on
   the difficulty in breaking local network.  This prevents the private keys used. The site
    security depends clients from checking with
   outside information sources. Servers on the sites protecting the private keys. By
    mandating one protocol at this point we also eliminate the need other hand are fully
   configured and can use any information sources accessible.

   Clients will not wait long for negotiating what authentication protocol to use. At this
    point OFFER message, some security checks
   may take longer than the public key algorithm has not been selected.  The two
    leading candidates DHCP retransmission timeout. If DHCP
   servers had an option to inform clients that DISCOVER messages
   are RSA being worked on and ECC (Elliptical Curve
    Cryptography).

4. 	General client should expect an answer in short
   order, then this problem would be solved.

   Some DHCP Client authentication protocol. servers do not have CPU cycles to spare to do security
   checks. This protocol depends on is a reliable certified public key
    distribution mechanism like DNSSEC[DNSSEC]. Each host bogus argument, since inexpensive powerful
   computers are available and server
    supplies it's identity, this identity indicates where the
    associated public key is stored. For DNS the identity sites should upgrade if security is FQDN
    (Fully Qualified Domain Name), accompanied by key algorithm
    number and public key footprint. For other key distribution
    mechanisms there must
   of concern.

3. DHCP Security components

3.1 Authentication services

   In order for DHCP servers to be enough information able to retrieve the key
    from that source. To successfully validate determine if a server public key,
    clients must client
   request should be configured with root key(s) for the key
    distribution certification tree.

    This protocol never transmits public keys as serviced it is easy essential for the server to forge
    self signed keys.  Instead certified keys be
   able to establish the client's identity. There are distributed via
    trusted 3rd party (eg. DNSSEC).  One two kinds of
   identities that are possible, local mutually agreed upon
   identities and global identities.

   Local identity is sufficient if the preconditions client will only be configured
   from a small set of
    this protocol is servers, and if there are no expectations
   that the client and server MUST roughly agree on
    current time.  The role 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 current time information below other hand is
    to prevent replay attacks. If needed when a client does not know the current
    time, it MUST request can
   connect to multiple servers and it before starting provides some of its
   identity.

   An example of local identity is a name or number that is
   configured in the authentication
    process. Servers client and Relay agents MUST provide current time upon
    request without any security checks.

    If server. This could be the client does not know name of the current time, it must be able to
    ask
   client on the local relay agent/server for the current 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 without
    authentication
   information that clients and get servers check and act upon. Clock
   synchronization service can be provided by an answer.

4.1. DHCP authentication protocol overview.

    In the following discussion, DHCP fields 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 important to the
    overall security schema are omitted.  Following protocol outline
    assumes trust time information
   from servers until after servers have been validated as such.
   Clients should always assume that the key distribution mechanism network is DNS.

Expires September 26, 1997                                     [Page  5]
    	1. Client:
    	Sends server discovery packet containing
    		Identity (this insecure.

3.3 Data confidentiality
   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 host identity, claimed identity,
		    charging identity)
    		client's own public key identity
    		Optionally its host identity the descibed models

3.4.1 The "No security" model

   This is the current time situation. The motivation for not changing
   anything is that security options/transformations supported is hard. Considering that DHCP requests for at least address, DNS server and gateway
		    address.
    		all preceding data IPv4 is signed
   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 private key
		    corresponding 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 public key specified above.

    	2. Server:
    	If current time 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 within accepted range
    	Look up 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 public key in key distribution mechanism
    	verify signature is this 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 connect?
    	If all above checks are passed communicate with the server sends back the
   server Public KEY  identity
    		Security will reply with OFFER message.

   In this model selected
    		key identifier ( if needed by security Model)
    		current time. 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
   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 requested authentication cannot be solved by
   IPSEC, as the client does not have an IP identity when it requests
   service for configuration (Address, DNS
		    server, gateway) 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 above signed by of their
   net identity  from DHCP. From a security point of view, the Server private KEY.

    	3. Client
   second type of client is no different, because these clients
   must have some identity (for example MAC address) that can now
    	configure itself
    	Look up 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 Public Key to
   server protocol. But in DNS.
    	if Server key many environments these weaker
   authentication mechanisms are adequate.

   The most general case is found, client SHOULD validate packet the identification of a computer that
   connects to a world wide ISP network and
	    Server KEY using DNS
    	client should also verify 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 DNS server is actually are allowed
   to connect.  From a valid
	    DNS server.
    	Sends server
    		key identifier requesting keying material
    		current time
    		signed by client public key

    	4. Server:
    	Server generates security standpoint it is a random key bad practice to use and it sends
   distribute shared secrets or passwords to client
    		key identifier
    	    	Keying material
    		Lifetime of the security association.
    		Current time
    		This data many places.

4.2. Motivation for single strong authentication schema.

   It is encrypted using clients public key

    The client decrypts the packet with its private key. At this
    point the client can assume its normal processing and send
    further requests better to server protected by the security model
    selected.  The mandate ONE strong authentication protocol for a relay agent is similar but is
    omitted here.

Expires September 26, 1997                                     [Page  6]

4.2. Additions all
   DHCP interaction, rather than allow for multiple ones and allow
   sites to choose the wrong one. The protocol overview. below uses strong
   authentication with public key signatures and encryption. The
   security of the protocol outlined above does not spell out all depends on the possible
    error states that can be entered. This needs to be specified difficulty in breaking
   the full protocol. Some of private keys used. The site security depends on the possible errors include sites
   protecting the
    following cases:

    What does private keys. By mandating one protocol at this
   point, we also eliminate the server do if it is unable need for negotiating what
   authentication protocol to retrieve/validate use. At this point, the
    client key?
    The Client in its verification phase must public key
   algorithm is MUST be able to determine
    what are RSA.

4.3 Motivation for global DNS identities for DHCP clients

   Once the authorized 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 servers. This may require has a new public key stored in DNS
    record, or use the SRV[SRV] record.
    What does a client do if then
   servers can verify digital signatures generated by that key.
   Once clients are configured it is not able possible for client to convince itself verify
   that the server it was configured by is talking to a good DHCP server?

    Due server. In
   order to do this, either SRV[SRV] records or ALLOC[DHCPVERSERV]
   DNS record must list the fact that some of the operations required by this
    protocol take longer than the time-out values in unsecured DHCP,
    these need to be changed for Security aware DHCP servers and clients.
    There may for each domain.

   IPSEC can be a need 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 server to send back an ACK to a key exchange once
   client
    indicating that a request has been received DHCP ACK message.

5. DHCP security options and is being
    processed to stop client from retransmitting requests.

    In their processing

5.1 DNS Identity option

   This option allows the case of security aware client trying DHCP entities to talk 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 security
    ignorant server be the server must return an error code informing same name
   that the client is requesting/using.

5.2 Signature option
   This is an option that it does not understand the request. Security
    aware servers similarly must treat security ignorant clients
    differently, but how must carries any type of signature that can be determined.

4.3.  Justification for the authentication protocol

    There
   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 number of reasons why the protocol does not attempt defined and must be supported by all
   implementations.

 	0		No signature data
 	1               RSA/MD5 as specified in PKCS1[NETSEC], this is
 			identical to
    create a security association algorithm 1 in the first round. By explicitly
    requesting the security association, the client DNSSEC.

 	100             HMAC-MD5 as specified in RFC2104[RFC2014]

   The ID is notifying the
    server a 16 bit number that it trusts the server and wants is identical to establish a long
    term relationship with it.  There the key indentifier
   in the DNSSEC SIG record. This identifier is no reason used to establish a
    security association with select a server
   key from the client does not trust. key set of the name. If a server selects a shared secret or encryption as a message
    protection mechanism then there are multiple keys in
   the key selected by the server is for
    use between one client set that match this ID and one server can be used for a limited 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
    there the signature is a group not
   within these bounds the whole packet should be rejected.

   The size of DHCP servers 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 site, then restricts
   the server
    to server protocol MAY be key sizes used to distribute about 1968 bits.

   The data covered by signatures is defined in section 5.3.1.  The
   Signature option MUST be the secret to all LAST option in the servers. If redundant servers do not share secrets then DHCP packet, adding
   a
    client Signature option MUST authenticate itself to each server.  If NOT result in too large of a security
    association outlives its lease time, it packet,
   other options MUST be renewed or
    deleted.

    In this protocol, there is no need for shared secrets removed to leave
    an administrative domain. This protocol solves the distribution
    problem of shared secrets and eliminates make space for the need signature
   option.

   There are special considerations for clients to
    remember shared secrets. The explicit expiration of shared
    secrets greatly simplifies server management of shared secrets.

    The only information Relay agents. A Relay Agent
   that adds a client needs relay agent option(s) to know is its own

Expires September 26, 1997                                     [Page  7]
    identity, a signed DHCP packet MUST
   add a Signature option after its public/private key pair option(s) and its signature
   MUST cover the root public key
    for whole outgoing packet.   If the key distribution mechanism. An added benefit of this
    protocol incoming
   signature is that it does not require the DHCP server addressed to store this Relay Agent, the authentication information for clients Relay Agent MUST
   remove that may connect to
    it. The public keys used are retrieved signature from an external source.
    This means that there will be minimal change in how servers are
    run. This protocol does not address the access control issue;
    that outgoing packet before adding its
   option(s) to the packet. If the incoming signature is a separate problem.

4.4. What does digital
   signature (alg=1) it MUST be retained.

5.3.1 Data covered by signature option

   The whole outgoing DHCP packet is covered, including the authentication protocol accomplish?

    This protocol accomplishes requirements 1 through 4. It carries
    enough information to enable requirement 5. signature
   option.

   For server and
    client to validate each other public keys they may want to walk DISCOVER/SOLICIT the DNS tree to signature is calculated over

 	Modified outgoing packet

   For all other messages the root to create a chain signature is calculated over

 	digest of last valid keys. incoming packet | Modified outgoing packet

   The
    client cannot trust the DNS server supplied by the server but it
    can trust the signed verifiable data that the DNS server
    provides. This requires that modified outgoing packet is the whole DHCP client packet with following
   differences:

 	'giaddr' and 'hops' fields must be able set to do
    DNSSEC verification locally.

    To determine that all zero.
 	All bytes in the Server is not an impostor there may signature data must be a
    need set 0xa6.

   The digest of the last incoming packet from the other entity is to store in DNS
   associate the list of authorized DHCP servers and
    agents in a zone.

    The "root keys" that client stores, can be outgoing packet to the keys for "." request or
    for last answer.

5.3 Wait option

   This option allows the outermost domain server to inform the client that it is
   currently validating the clients identity and request that the
   client can talk to servers in.

    The main reason for having the server select wait the secret keying
    material for specified time before retransmitting the security association, has query.

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

   This option is to do with random
    number entropy.  Many computers do not have good sources of
    randomness available at boot time.  A throttle back security aware clients while server that has been
    running for a while, on
   is authenticating the other hand, has access to better
    sources of randomness. clients identity. The protocol when specified should
    include guidelines on how to generate good random keys on
    servers.

5. Protecting ongoing client/server communication

    Rule 5 above states that client (or relay agent) and MUST ignore
   this option if it has received 2 previous ones from same server must
    agree on a security model
   for securing all communication. The the same message.

6. "Simple" DHCP authentication protocol above  accomplishes the required dynamic
    setup for this. Once a security aware Server and security aware
    Client have authenticated each other they have entered a
    security association.

   This security association will determine
    how all successive communication is protected. Below protocol is a list
    of available mechanisms that accomplish this task.
    	A.  None  (Current state of affairs) NOT recommended
    	B.  Message digest with shared secret. (Protects along the contents lines of the packet).
    	C.  Digital signature.  (Provides more assurance at higher
	    cost).
    	D.  Encrypted communication  (Provides confidentiality).
    	E.  IPSEC.

Expires September 26, 1997                                     [Page  8] simple model described in
   section 3.4.2. The author feels foundation that mechanisms B and D are the only ones
    practical for DHCP. Digital signatures are not worth the
    computational and bandwidth cost for one this protocol offers can be used
   to build a comprehensive protocol.

   This protocol depends on one communication.
    IPSEC will become viable at some point a reliable certified public key
   distribution mechanism like DNSSEC[DNSSEC]. Each client supplies
   its identity in the future 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 can/
    should public key footprint. For other
   key distribution mechanisms there must be used to protect the communication. The working group
    needs to decide whether enough information to deploy a message protection mechanism
    in

Expires January 30, 1998                                        [Page10]
   retrieve the DHCP protocol or wait for IPSEC. This document recommends key from that B source.

   To successfully validate a server public key, clients must be implemented using HMAC[HMAC] technique combined
   configured with
    one 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 message digest algorithms MD5, SHA-1 or
    RIPEMD-160.

    Digital signatures provide a stronger authentication mechanism
    than Message digests but are much more expensive discussion, DHCP options not important to generate.
    Some Digital signatures the
   overall schema are inexpensive to verify but not all.
    RSA 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 inexpensive 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 but DSA this message, it has authenticated
   the server and the authentication protocol is not. Given complete. Future
   communication can be protected by this secret.

   If the expensive
    computation of digital signatures it server is hard able to justify their
    use once identity has been established.

6. Impact of Agents on security model.

    Given validate DISCOVER message from a client
   that in many cases clients need Agents to connect them 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
    DHCP servers, complete authentication it is important that agents cannot modify can send
   back

 	WAIT option
 	Signature option 0

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

 	IDENTITY option
 	Signature option

   If server is also important that Agents unable to authenticate the identity of the client, the

Expires January 30, 1998                                        [Page11]
   server advertisements. Agents should not be allowed
    to modify MUST ignore the client requests in any way, other than that required
    to route messages. The server SHOULD log the
   event and CAN ignore requests from the requests. There is no need 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 to enter
    a security association with its Relay Agent.

6.1. Server/Relay agent advertisements.

    This is a special case where one entity is talking to many.  In
    order to protect can now
   send the REQUEST message, and this form of communication from malicious
    attacks these advertisements message MUST be digitally signed using the
    advertisers by its
   public key. It is possible to create a group shared
    secret or group encryption key. This is not a good arrangement key in order for anything other servers to verify that lasts longer than a short time. Short time can their
   offers were declined. The following options MUST be present:

 	IDENTITY
 	Security option (alg=1)

6.2 Future communication

   Once a few minutes to a few hours; longer than client that it is does not share a
    secure arrangement. If one party leaks this key information,
    outsiders can forge traffic.

6.2. Security threats from relay agents.

    Relay agents secret with the server selected
   has been configured, it can potentially conduct "man in optionally authenticate the middle" attacks
    on a system that uses them. In server as
   specified in[DHCPVERSERV].  All future communiction between the schema above relay agents can
    conduct denial of service attacks.  This is a simple fact of
    life
   client and there 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 no way available it
   CAN be used to overcome that.

    It protect future communication until the client is not clear that relay agents
   renumbered.  The client and server can conduct any other kind of
    attacks as they are not able also elect to forge any use RSA
   signatures on all communication.

6.3 Computational complexity of Simple Authentication Protocol

   This protocol places most of the contents cost of the
    packets.

    In 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 case where clients do not validate that public keys of the server
    contacted is client can be to a valid server, relay agents may conduct attacks as

Expires September 26, 1997                                     [Page  9]
    fake server. In this attack the relay agent claims
   large extent offloaded to be the DNSSEC server if a DNS transaction
   signature mechanism[RFC2065,TSIG] is used to protect the client
   communication.

6.4 Client security requirements

   Security enabled DHCP clients MUST be able to store their identity
   and the 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 server.
    Careful design 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 the protocol should clients. Servers MUST be able
   to prevent this. 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]

7. Security considerations

   This document is about security.

8. addresses how to add security features to the
   unsecured DHCP protocol.

7. References

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

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

    [DNSSEC] D. Eastlake,

     [DHCPv6] J. Bound, C. Kaufman, "Domain Name System Security
    Extensions", RFC 2065, January Perkins,
     "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     [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.

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

     [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]
     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]