WDIFF

draft-ietf-dhc-authentication-02.txt --> draft-ietf-dhc-authentication-03.txt

Network Working Group R. Droms (Editor) Droms, Editor
INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-authentication-01.txt February draft-ietf-dhc-authentication-02.txt November 1996
Expires August 1996 May 1997

Authentication for DHCP Messages
<draft-ietf-dhc-authentication-02.txt>
<draft-ietf-dhc-authentication-03.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

The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
client
authentication of DHCP messages from DHCP servers. The goal the source and contents of
this proposal is to suggest DHCP messages. This
document defines a technique new DHCP option through which authorization
tickets can be easily generated and newly attached hosts with proper
authorization can be automatically configured from an authenticated
DHCP server.

1. Introduction

DHCP transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating
a manual step in configuration of TCP/IP hosts.

Droms [Page 1]

DRAFT Authentication for DHCP Messages February November 1996

In some situations, network administrators may wish to constrain the
allocation of addresses to authorized hosts. Such constraint may be
desirable in "hostile" environments where the network medium is not
physically secured, such as wireless networks or college residence
halls.

Additionally, some

Some network administrators may wish to provide authentication of the
source and contents of DHCP messages from DHCP servers. In some
environments, messages. For example, 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 Network administrators may wish to
constrain the allocation of this proposal is addresses to suggest a technique through which
authorization tickets can be easily generated and newly attached authorized hosts with proper authorization can be automatically configured from
an authenticated DHCP server.

Overview

The idea behind this proposal is to use well-known techniques to
authenticate the source and contents avoid
denial of DHCP messages. Each
authenticated DHCP message will include an encrypted value generated
by service attacks in "hostile" environments where the source network
medium is not physically secured, such as wireless networks or
college residence halls.

This document defines a message technique that can provide both entity
authentication code (MAC), and will
contain a message digest confirming authentication.

1.1 Requirements

Throughout this document, the words that are used to define the message contents have
not been altered in transit.

There is one "feature"
significance of DHCP particular requirements are capitalized. These words
are:

o "MUST"

This word or the adjective "REQUIRED" means that complicates the authentication of
DHCP messages. DHCP clients use limited broadcast for all messages.
To allow for delivery
item is an absolute requirement of DHCP messages to servers this specification.

o "MUST NOT"

This phrase means that are not on the
same subnet, a DHCP relay agent on the same subnet as item is an absolute prohibition
of this specification.

o "SHOULD"

This word or the client
receives adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore
this item, but the initial message full implications should be understood and forwards
the message on to case carefully weighed before choosing a different course.

o "SHOULD NOT"

This phrase means that there may exist valid reasons in
particular circumstances when the DHCP
server. The relay agent changes listed behavior is acceptable
or even useful, but the contents of two fields -
'giaddr' full implications should be understood
and 'hops' - in the case carefully weighed before implementing any behavior
described with this label.

Droms [Page 2]

DRAFT Authentication for DHCP message. Thus, Messages November 1996

o "MAY"

This word or the message digest,
which adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to be computed by include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.

1.2 Terminology

This document uses the following terms:

o "DHCP client"

A DHCP client and confirmed by or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.

o "DHCP server"

A DHCP server of "server"is an Internet host that returns
configuration parameters to DHCP clients.

2. Format of the server,
cannot include authentication option

The following diagram defines the 'giaddr' and 'hops' fields.

Message format of the DHCP
authentication

Suppose option:

The code for the sender, S, and receiver, R, share a secret key, K, where
K authentication option is unique to any messages exchanged between S TBD, and R. S the length field
contains the length of the protocol and R are a
DHCP client/server pair. S forms authentication information
fields in octets. The protocol field defines the MAC by encoding a counter value
with K. particular
technique for authentication used in the option.

This counter should be monotonically increasing document defines two protocols in sections 3 and 4, encoded with
protocol field values 0 and large
enough 1. Protocol field values 2-254 are
reserved for future use. Other protocols may be defined according to hold an NTP-format timestamp. The MAC:

counter, f(K, MD(message + counter))

(where MD is a message digest function as specified below) is
included
the procedure described in section 5.

3. Protocol 0

If the DHCP message generated by S. Encoding function f protocol field is 0, the authentication information field

Droms [Page 2] 3]

DRAFT Authentication for DHCP Messages February November 1996

must have

holds a simple authentication token:

+----------+----------+----------+
| Code | n+1 | 0 |
+----------+----------+----------+-----------+------
| Authentication token (n octets) ...
+----------+----------+----------+-----------+------

The authentication token is an opaque, unencoded value known to both
the characteristics that K cannot be deduced sender and receiver. The sender inserts the authentication token
in the DHCP message and the receiver matches the token from the MAC
message to the shared token. If the authentication option is present
and f(K, MD(message + counter)) can't the token from the message does not match the shared token, the
receiver MUST discard the message.

Protocol 0 may be guessed. R can then compute
f(K, MD(message + counter)) used to verify that S must have known K.
Using pass a counter value 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 the current time
a plain-text password. Other types of day can reduce the
danger of replay attacks.

Key management

Assume that entity authentication using
computed tokens such as Kerberos tickets or one-time passwords
will be defined as separate protocols.

4. Protocol 1

If the shared key, K, protocol field is distributed 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 client through
some out-of-band mechanism. The client must store K locally HMAC protocol [3] using the MD5 hash
{2].

Droms [Page 4]

DRAFT Authentication for use
in all authenticated DHCP messages. Messages November 1996

4.1 Format

The server must know format of the Ks authentication information for
all authorized clients.

To avoid centralized management of a list protocol 1 is:

+----------+----------+----------+
| Code | n | 1 |
+----------+----------+----------+----------+-
| Counter (8 octets) ...
+----------+----------+----------+----------+-
| MAC ...
+----------+----------+----------+----------+-

The following definitions will be used in the description of random keys, suppose K the
authentication information for each client is generated from some value unique to that client.
That is, protocol 1:

K = f(MK, unique-id), where MK is - a secret master key and f
is an encoding function as described above.

Each DHCP client must have a unique "client-id" through which its
interactions with value shared between the DHCP server (specifically, source and destination
of the address
currently allocated to message
Counter - the client) can be identified. This client-id
may be value of a 64-bit monotonically increasing counter
HMAC-MD5 - the MAC address or a manufacturer's serial number; generating function as defined by [3] and [2]

The sender computes the specific
choice MAC as described in [3]. The 'counter' field
of client-id is left the authentication option MUST be set to the network administrator. The
client-id meets value of a
monotonically increasing counter and the requirements 'MAC' field of the unique-id used
authentication option MUST be set to generate K
in all 0s for the previous paragraph.

Without knowledge computation of
the master key MK, an unauthorized client cannot
generate its own key K. The server can quickly validate an incoming
message from MAC. Because a new client by regenerating K from the client-id. For
known clients, the server can choose to recover DHCP relay agent may alter the client's K
dynamically from values of the client-id
'giaddr' and 'hops' fields in the DHCP message, or can choose the contents of those
two fields MUST also be set to
precompute and cache all zero for the computation of the Ks
message digest. Using a priori.

Selection of encoding function

The exact encoding function is TBD. One suggestion is to borrow from
DNSSEC, in which counter value such as the encoding function is designated by current time of
day (e.g., an identifier
in NTP-format timestamp [4]) can reduce the message. The identifier then selects no encoding, a default
encoding (using danger of
replay attacks.

DISCUSSION:

Protocol 1 specifies the Public Key Cryptographic Standard use of HMAC-MD5. Use of a different
technique, such as specified in
DNSSEC) which must HMAC-SHA, will be provided, or one of several other optional
encodings.

Message contents verification

MD5 is specified as a well-known mechanism for generating 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 digest that can
confirm value larger than the last value of
'counter' used by the sender, the receiver MUST discard the incoming
message. The receiver MUST set the contents 'MAC' field of a message have not been altered in
transit. The only modification the authentication
option to MD5 all 0s for use in computation of the MAC. Because a DHCP is to require
that 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 all 0s for the MD5

Droms [Page 3] 5]

DRAFT Authentication for DHCP Messages February November 1996

computation.

Message contents

Putting all

zero for the computation of this together, S builds: 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, counter, f(K, MD5(message - ('giaddr' 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 'hops') +
counter))

where K is to authenticate and verify any
messages it receives from the server. The client's key. R can then verify key must be
initially distributed to the contents of client through some out-of-band
mechanism, and must be stored locally on the
message from client for use in all
authenticated DHCP messages. Once the MD5 digest value, and verify client has been given its key,
it may use that S 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 have held know the shared secret key from keys for all authorized clients. If
all clients use the value of f(K, MD5(message - ('giaddr'
and 'hops') + counter))

Applicability same key, clients can perform both entity and Specification

This scheme is equally applicable
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 both DHCPv4
and DHCPv6 messages. If this mechanism is adopted 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 part of an Internet Standard.
4. The new protocol progresses through the
DHCPv4 or DHCPv6 specification, IETF standards process;
the authentication data new option will be
encoded reviewed by the Dynamic Host Configuration
Working Group (if that group still exists), or as an option. 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.

Droms [Page 6]

DRAFT Authentication for DHCP Messages November 1996

6. References

[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993.

[2] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992.

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

[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 1996. 1995. The
editor of this document
author transcribed the notes from that discussion. 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 Thomas Narten Shawn Mamros for
reviewing
a draft of this proposal, document, and to Shawn Mamros for noticing that the
original draft neglected to account Thomas Narten for the 'hops' field.

References

[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993. reviewing earlier
drafts of this document.

8. Security Considerations considerations

This memo document describes authentication and verification mechanisms
for DHCP

Editor's Address DHCP.

9. Author's address

Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837

Phone: (717) 524-1145
EMail: droms@bucknell.edu

Droms [Page 4] 7]

DRAFT Authentication for DHCP Messages February 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.

Droms [Page 5] 8]

----