draft-ietf-dhc-authentication-02.txt   draft-ietf-dhc-authentication-03.txt 
Network Working Group R. Droms (Editor) Network Working Group R. Droms, Editor
INTERNET DRAFT Bucknell University INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-authentication-01.txt February 1996 Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996
Expires August 1996 Expires May 1997
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-02.txt> <draft-ietf-dhc-authentication-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 36 skipping to change at page 1, line 36
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] provides a The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts. constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for Additionally, some network administrators may wish to provide for
client authentication of DHCP messages from DHCP servers. The goal of authentication of the source and contents of DHCP messages. This
this proposal is to suggest a technique through which authorization document defines a new DHCP option through which authorization
tickets can be easily generated and newly attached hosts with proper tickets can be easily generated and newly attached hosts with proper
authorization can be automatically configured from an authenticated authorization can be automatically configured from an authenticated
DHCP server. DHCP server.
Introduction 1. Introduction
DHCP transports protocol stack configuration parameters from DHCP transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating dynamically allocate addresses from a pool of addresses, eliminating
a manual step in configuration of TCP/IP hosts. a manual step in configuration of TCP/IP hosts.
DRAFT Authentication for DHCP Messages February 1996 DRAFT Authentication for DHCP Messages November 1996
In some situations, network administrators may wish to constrain the Some network administrators may wish to provide authentication of the
allocation of addresses to authorized hosts. Such constraint may be source and contents of DHCP messages. For example, clients may be
desirable in "hostile" environments where the network medium is not subject to denial of service attacks through the use of bogus DHCP
physically secured, such as wireless networks or college residence servers, or may simply be misconfigured due to unintentionally
halls. instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network
medium is not physically secured, such as wireless networks or
college residence halls.
Additionally, some network administrators may wish to provide This document defines a technique that can provide both entity
authentication of DHCP messages from DHCP servers. In some authentication and message authentication.
environments, clients may be subject to denial of service attacks
through the use of bogus DHCP servers, or may simply be misconfigured
due to unintentionally instantiated DHCP servers.
The goal of this proposal is to suggest a technique through which 1.1 Requirements
authorization tickets can be easily generated and newly attached
hosts with proper authorization can be automatically configured from
an authenticated DHCP server.
Overview Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
are:
The idea behind this proposal is to use well-known techniques to o "MUST"
authenticate the source and contents of DHCP messages. Each
authenticated DHCP message will include an encrypted value generated
by the source as a message authentication code (MAC), and will
contain a message digest confirming that the message contents have
not been altered in transit.
There is one "feature" of DHCP that complicates the authentication of This word or the adjective "REQUIRED" means that the
DHCP messages. DHCP clients use limited broadcast for all messages. item is an absolute requirement of this specification.
To allow for delivery of DHCP messages to servers that are not on the
same subnet, a DHCP relay agent on the same subnet as the client
receives the initial message and forwards the message on to the DHCP
server. The relay agent changes the contents of two fields -
'giaddr' and 'hops' - in the DHCP message. Thus, the message digest,
which is to be computed by the client and confirmed by the server,
cannot include the 'giaddr' and 'hops' fields.
Message authentication o "MUST NOT"
Suppose the sender, S, and receiver, R, share a secret key, K, where This phrase means that the item is an absolute prohibition
K is unique to any messages exchanged between S and R. S and R are a of this specification.
DHCP client/server pair. S forms the MAC by encoding a counter value
with K. This counter should be monotonically increasing and large
enough to hold an NTP-format timestamp. The MAC:
counter, f(K, MD(message + counter)) o "SHOULD"
(where MD is a message digest function as specified below) is This word or the adjective "RECOMMENDED" means that there
included in the DHCP message generated by S. Encoding function f may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
DRAFT Authentication for DHCP Messages February 1996 o "SHOULD NOT"
must have the characteristics that K cannot be deduced from the MAC This phrase means that there may exist valid reasons in
and f(K, MD(message + counter)) can't be guessed. R can then compute particular circumstances when the listed behavior is acceptable
f(K, MD(message + counter)) to verify that S must have known K. or even useful, but the full implications should be understood
Using a counter value such as the current time of day can reduce the and the case carefully weighed before implementing any behavior
danger of replay attacks. described with this label.
Key management DRAFT Authentication for DHCP Messages November 1996
Assume that the shared key, K, is distributed to the client through o "MAY"
some out-of-band mechanism. The client must store K locally for use
in all authenticated DHCP messages. The server must know the Ks for
all authorized clients.
To avoid centralized management of a list of random keys, suppose K This word or the adjective "OPTIONAL" means that this item is
for each client is generated from some value unique to that client. truly optional. One vendor may choose to include the item
That is, K = f(MK, unique-id), where MK is a secret master key and f because a particular marketplace requires it or because it
is an encoding function as described above. enhances the product, for example; another vendor may omit the
same item.
Each DHCP client must have a unique "client-id" through which its 1.2 Terminology
interactions with the DHCP server (specifically, the address
currently allocated to the client) can be identified. This client-id
may be a MAC address or a manufacturer's serial number; the specific
choice of client-id is left to the network administrator. The
client-id meets the requirements of the unique-id used to generate K
in the previous paragraph.
Without knowledge of the master key MK, an unauthorized client cannot This document uses the following terms:
generate its own key K. The server can quickly validate an incoming
message from a new client by regenerating K from the client-id. For
known clients, the server can choose to recover the client's K
dynamically from the client-id in the DHCP message, or can choose to
precompute and cache all of the Ks a priori.
Selection of encoding function o "DHCP client"
The exact encoding function is TBD. One suggestion is to borrow from A DHCP client or "client" is an Internet host using DHCP to obtain
DNSSEC, in which the encoding function is designated by an identifier configuration parameters such as a network address.
in the message. The identifier then selects no encoding, a default
encoding (using the Public Key Cryptographic Standard as specified in
DNSSEC) which must be provided, or one of several other optional
encodings.
Message contents verification o "DHCP server"
MD5 is a well-known mechanism for generating a digest that can A DHCP server of "server"is an Internet host that returns
confirm the the contents of a message have not been altered in configuration parameters to DHCP clients.
transit. The only modification to MD5 for use in DHCP is to require
that the 'giaddr' and 'hops' fields be set to all 0s for the MD5
DRAFT Authentication for DHCP Messages February 1996 2. Format of the authentication option
computation. The following diagram defines the format of the DHCP
authentication option:
Message contents +----------+----------+----------+
| Code | Length | Protocol |
+----------+----------+----------+-----------+---
| Authentication information ...
+----------+----------+----------+-----------+---
Putting all of this together, S builds: The code for the authentication option is TBD, and the length field
contains the length of the protocol and authentication information
fields in octets. The protocol field defines the particular
technique for authentication used in the option.
DHCP message, counter, f(K, MD5(message - ('giaddr' and 'hops') + This document defines two protocols in sections 3 and 4, encoded with
counter)) protocol field values 0 and 1. Protocol field values 2-254 are
reserved for future use. Other protocols may be defined according to
the procedure described in section 5.
where K is the client's key. R can then verify the contents of the 3. Protocol 0
message from the MD5 digest value, and verify that S must have held
the shared secret key from the value of f(K, MD5(message - ('giaddr'
and 'hops') + counter))
Applicability and Specification If the protocol field is 0, the authentication information field
This scheme is equally applicable to authentication of both DHCPv4 DRAFT Authentication for DHCP Messages November 1996
and DHCPv6 messages. If this mechanism is adopted as part of the
DHCPv4 or DHCPv6 specification, the authentication data will be
encoded as an option.
Acknowledgments holds a simple authentication token:
Jeff Schiller and Christian Huitema developed this scheme during a +----------+----------+----------+
terminal room BOF at the Dallas IETF meeting, December 1996. The | Code | n+1 | 0 |
editor of this document transcribed the notes from that discussion. +----------+----------+----------+-----------+------
Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing | Authentication token (n octets) ...
a draft of this proposal, and to Shawn Mamros for noticing that the +----------+----------+----------+-----------+------
original draft neglected to account for the 'hops' field.
References The authentication token is an opaque, unencoded value known to both
the sender and receiver. The sender inserts the authentication token
in the DHCP message and the receiver matches the token from the
message to the shared token. If the authentication option is present
and the token from the message does not match the shared token, the
receiver MUST discard the message.
Protocol 0 may be used to pass a plain-text password and provides
only weak entity authentication and no message authentication. This
protocol is useful for rudimentary protection against, e.g.,
inadvertently instantiated DHCP servers.
DISCUSSION:
The intent here is to pass a constant, non-computed token such as
a plain-text password. Other types of entity authentication using
computed tokens such as Kerberos tickets or one-time passwords
will be defined as separate protocols.
4. Protocol 1
If the protocol field is 1, the authentication information contains
an encrypted value generated by the source as a message
authentication code (MAC) to provide message authentication and
entity authentication.
This technique is based on the HMAC protocol [3] using the MD5 hash
{2].
DRAFT Authentication for DHCP Messages November 1996
4.1 Format
The format of the authentication information for protocol 1 is:
+----------+----------+----------+
| Code | n | 1 |
+----------+----------+----------+----------+-
| Counter (8 octets) ...
+----------+----------+----------+----------+-
| MAC ...
+----------+----------+----------+----------+-
The following definitions will be used in the description of the
authentication information for protocol 1:
K - a secret value shared between the source and destination
of the message
Counter - the value of a 64-bit monotonically increasing counter
HMAC-MD5 - the MAC generating function as defined by [3] and [2]
The sender computes the MAC as described in [3]. The 'counter' field
of the authentication option MUST be set to the value of a
monotonically increasing counter and the 'MAC' field of the
authentication option MUST be set to all 0s for the computation of
the MAC. Because a DHCP relay agent may alter the values of the
'giaddr' and 'hops' fields in the DHCP message, the contents of those
two fields MUST also be set to zero for the computation of the
message digest. Using a counter value such as the current time of
day (e.g., an NTP-format timestamp [4]) can reduce the danger of
replay attacks.
DISCUSSION:
Protocol 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
protocol.
4.2 Message validation
To validate an incoming message, the receiver checks the 'counter'
field and computes the MAC as described in [3]. If the 'counter'
field does not contain a value larger than the last value of
'counter' used by the sender, the receiver MUST discard the incoming
message. The receiver MUST set the 'MAC' field of the authentication
option to all 0s for computation of the MAC. Because a DHCP relay
agent may alter the values of the 'giaddr' and 'hops' fields in the
DHCP message, the contents of those two fields MUST also be set to
DRAFT Authentication for DHCP Messages November 1996
zero for the computation of the MAC. If the MAC computed by the
receiver does not match the MAC contained in the authentication
option, the receiver MUST discard the DHCP message.
4.3 Key utilization
Each DHCP client has a key, K. The client uses its key to encode any
messages it sends to the server and to authenticate and verify any
messages it receives from the server. The client's key must be
initially distributed to the client through some out-of-band
mechanism, and must be stored locally on the client for use in all
authenticated DHCP messages. Once the client has been given its key,
it may use that key for all transactions even if the client's
configuration changes; e.g., if the client is assigned a new network
address.
Each DHCP server must know the keys for all authorized clients. If
all clients use the same key, clients can perform both entity and
message authentication for all messages received from servers.
Servers will be able to perform message authentication. To
authenticate the identity of individual clients, each client must be
configured with a unique key. Appendix A describes a technique for
key management.
5. Definition of new authentication protocols
The author of a new DHCP option will follow these steps to obtain
acceptance of the option as a part of the DHCP Internet Standard:
1. The author devises the new authentication protocol.
2. The author documents the new protocol as an Internet Draft.
3. The author submits the Internet Draft for review through the IETF
standards process as defined in "Internet Official Protocol
Standards" (STD 1). The new protocol will be submitted for
eventual acceptance as an Internet Standard.
4. The new protocol progresses through the IETF standards process;
the new option will be reviewed by the Dynamic Host Configuration
Working Group (if that group still exists), or as an Internet
Draft not submitted by an IETF working group.
This procedure for defining new authentication protocols will ensure
that:
* new options are reviewed for technical correctness and
appropriateness, and
* documentation for new options is complete and published.
DRAFT Authentication for DHCP Messages November 1996
6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993. Bucknell University, October 1993.
Security Considerations [2] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992.
This memo describes authentication and verification mechanisms for DHCP [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
progress), August 1996.
Editor's Address [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
1992.
7. Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1995. The
author transcribed the notes from that discussion, which form the
basis for this document. The editor appreciates Jeff's and
Christian's patience in reviewing this document and its earlier
drafts.
Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for
reviewing this document, and to Thomas Narten for reviewing earlier
drafts of this document.
8. Security considerations
This document describes authentication and verification mechanisms
for DHCP.
9. Author's address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu
DRAFT Authentication for DHCP Messages February 1996 DRAFT Authentication for DHCP Messages November 1996
EMail: droms@bucknell.edu Appendix A - Key Management Technique
To avoid centralized management of a list of random keys, suppose K for
each client is generated from the pair (client identifier, subnet
address), which must be unique to that client. That is, K = MD5(MK,
unique-id), where MK is a secret master key and MD5 is some encoding
function.
Without knowledge of the master key MK, an unauthorized client cannot
generate its own key K. The server can quickly validate an incoming
message from a new client by regenerating K from the client-id. For known
clients, the server can choose to recover the client's K dynamically from
the client-id in the DHCP message, or can choose to precompute and cache
all of the Ks a priori.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/