Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/dist/dhcp/doc/draft-ietf-dhc-authenticati...

894 lines
34 KiB
Plaintext
Raw Normal View History

import of ISC dhcp-3.0rc10
2001-08-03 15:35:28 +04:00
Network Working Group R. Droms, Editor
INTERNET DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-authentication-13.txt W. Arbaugh, Editor
University of Maryland
July 2000
Expires December 2000
Authentication for DHCP Messages
<draft-ietf-dhc-authentication-14.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt, and the list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Dynamic Host Configuration Protocol (DHCP) 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 authentication of the
source and contents of DHCP messages. This document defines a 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 [1] 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
Droms, Arbaugh [Page 1]
DRAFT Authentication for DHCP Messages March 2000
a manual step in configuration of TCP/IP hosts.
Some network administrators may wish to provide authentication of the
source and contents of DHCP 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. 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.
This document defines a technique that can provide both entity
authentication and message authentication.
DISCUSSION:
This draft combines the original Schiller-Huitema-Droms
authentication mechanism defined in a previous Internet Draft with
the "delayed authentication" proposal developed by Bill Arbaugh.
1.1 DHCP threat model
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where BOOTP ports are blocked on the
enterprise's perimeter gateways.) Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
The attack specific to a DHCP client is the possibility of the
establishment of a "rogue" server with the intent of providing
incorrect configuration information to the client. The motivation for
doing so may be to establish a "man in the middle" attack or it may
be for a "denial of service" attack.
There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of
nefarious purposes.
The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve the
exhaustion of valid addresses, or the exhaustion of CPU or network
bandwidth, and are present anytime there is a shared resource. In
Droms, Arbaugh [Page 2]
DRAFT Authentication for DHCP Messages March 2000
current practice, redundancy mitigates DoS attacks the best.
1.2 Design goals
These are the goals that were used in the development of the
authentication protocol, listed in order of importance:
1. Address the threats presented in Section 1.1.
2. Avoid changing the current protocol.
3. Limit state required by the server.
4. Limit complexity (complexity breeds design and implementation
errors).
1.3 Requirements Terminology
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 [5].
1.4 DHCP Terminology
This document uses the following terms:
o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP server"
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
2. Format of the authentication option
The following diagram defines the format of the DHCP
authentication option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
+-+-+-+-+-+-+-+-+ |
Droms, Arbaugh [Page 3]
DRAFT Authentication for DHCP Messages March 2000
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the authentication option is TBD, and the length field
contains the length of the protocol, RDM, algorithm, Replay Detection
fields and authentication information fields in octets.
The protocol field defines the particular technique for
authentication used in the option. New protocols are defined as
described in Section 6.
The algorithm field defines the specific algorithm within the
technique identified by the protocol field.
The Replay Detection field is per the RDM, and the authentication
information field is per the protocol in use.
The Replay Detection Method (RDM) field determines the type of replay
detection used in the Replay Detection field.
If the RDM field contains 0x00, the replay detection field MUST be
set to the value of a monotonically increasing counter. 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. This
method MUST be supported by all protocols.
Other values of the RDM field are reserved for future definition
according to the procedures described in section 6.
This document defines two protocols in sections 4 and 5, encoded with
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 6.
3. Interaction with Relay Agents
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 be set to zero for the computation of any hash function over the
message header. Additionally, a relay agent may append the DHCP relay
agent information option 82 [7] as the last option in a message to
servers. If a server finds option 82 included in a received message,
the server MUST compute any hash function as if the option were NOT
included in the message without changing the order of options.
Droms, Arbaugh [Page 4]
DRAFT Authentication for DHCP Messages March 2000
Whenever the server sends back option 82 to a relay agent, the server
MUST not include the option in the computation of any hash function
over the message.
4. Protocol 0
If the protocol field is 0, the authentication information field
holds a simple authentication token:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
+-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 only useful for rudimentary protection against
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.
5. Protocol 1
Droms, Arbaugh [Page 5]
DRAFT Authentication for DHCP Messages March 2000
If the protocol field is 1, the message is using the "delayed
authentication" mechanism. In delayed authentication, the client
requests authentication in its DHCPDISCOVER message and the server
replies with a DHCPOFFER message that includes authentication
information. This authentication information contains a nonce value
generated by the source as a message authentication code (MAC) to
provide message authentication and entity authentication.
This document defines the use of a particular technique based on the
HMAC protocol [3] using the MD5 hash [2].
5.1 Management Issues
The "delayed authentication" protocol does not attempt to address
situations where a client may roam from one administrative domain to
another, i.e. interdomain roaming. This protocol is focused on
solving the intradomain problem where the out-of-band exchange of a
shared secret is feasible.
5.2 Format
The format of the authentication request in a DHCPDISCOVER message
for protocol 1 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+
The format of the authentication information for protocol 1 is:
Droms, Arbaugh [Page 6]
DRAFT Authentication for DHCP Messages March 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret id cont| HMAC-MD5 (128 bits) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines one technique for use with protocol 1, which is
identified by setting the algorithm field to 1. Other techniques
that use different algorithms may be defined by future
specifications, see section 6. The following definitions will be
used in the description of the authentication information for
protocol 1, algorithm 1:
Replay Detection - as defined by the RDM field
K - a secret value shared between the source and
destination of the message; each secret has a
unique identifier (not shown in figures)
secret ID - the unique identifier for the secret value
used to generate the MAC for this message
HMAC-MD5 - the MAC generating function [3, 2].
The sender computes the MAC using the HMAC generation algorithm [3]
and the MD5 hash function [2]. The entire DHCP message (except as
noted below), including the DHCP message header and the options
field, is used as input to the HMAC-MD5 computation function. The
'secret ID' field MUST be set to the identifier of the secret used to
generate the MAC.
DISCUSSION:
Algorithm 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
protocol.
Protocol 1 requires a shared secret key for each client on each
DHCP server with which that client may wish to use the DHCP
protocol. Each secret key has a unique identifier that can be
used by a receiver to determine which secret was used to generate
the MAC in the DHCP message. Therefore, protocol 1 may not scale
well in an architecture in which a DHCP client connects to
multiple administrative domains.
Droms, Arbaugh [Page 7]
DRAFT Authentication for DHCP Messages March 2000
Note that the meaning of an authentication option can be changed
by removing the secret ID, and MAC, transforming an authentication
option with authentication information into a request for
authentication. Therefore, the authentication request form of
this option can only appear in a DHCPDISCOVER message or a
DHCPINFORM message.
5.3 Message validation
To validate an incoming message, the receiver first checks that
the value in the replay detection field is acceptable according to
the replay detection method specified by the RDM field. Next, the
receiver computes the MAC as described in [3]. The receiver MUST
set the 'MAC' field of the authentication option to all 0s for
computation of the MAC, and 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 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.
Section 3 provides additional information on handling messages
that include option 82 (Relay Agents).
5.4 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 SHOULD
be initially distributed to the client through some out-of-band
mechanism, and SHOULD be stored locally on the client for use in
all authenticated DHCP messages. Once the client has been given
its key, it SHOULD 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, or be able to obtain in a secure
manner, 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. However,
the sharing of keys is strongly discouraged as it allows for
unauthorized clients to masquerade as authorized clients by
obtaining a copy of the shared key. 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.5 Client considerations
Droms, Arbaugh [Page 8]
DRAFT Authentication for DHCP Messages March 2000
This section describes the behavior of a DHCP client using
authentication protocol 1.
5.5.1 INIT state
When in INIT state, the client uses protocol 1 as follows:
1. The client MUST include the authentication request option in
its DHCPDISCOVER message along with option 61 [6] to identify
itself uniquely to the server.
2. The client MUST validate any DHCPOFFER messages that include
authentication information using the mechanism specified in
section 5.3. The client MUST discard any messages which fail
to pass validation and MAY log the validation failure. The
client selects one DHCPOFFER message as its selected
configuration. If none of the DHCPOFFER messages received by
the client include authentication information, the client MAY
choose an unauthenticated message as its selected
configuration. The client SHOULD be configurable to accept or
reject unauthenticated DHCPOFFER messages.
3. The client replies with a DHCPREQUEST message that MUST include
authentication information encoded with the same secret used by
the server in the selected DHCPOFFER message.
4. The client MUST validate the DHCPACK message from the server.
The client MUST discard the DHCPACK if the message fails to
pass validation and MAY log the validation failure. If the
DHCPACK fails to pass validation, the client MUST revert to
INIT state and returns to step 1. The client MAY choose to
remember which server replied with a DHCPACK message that
failed to pass validation and discard subsequent messages from
that server.
5.5.2 INIT-REBOOT state
When in INIT-REBOOT state, the client MUST use the secret it used
in its DHCPREQUEST message to obtain its current configuration to
generate authentication information for the DHCPREQUEST message.
The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK
messages if no authenticated messages were received. The client
MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
messages as specified in section 3.2 of [1].
5.5.3 RENEWING state
When in RENEWING state, the client uses the secret it used in its
initial DHCPREQUEST message to obtain its current configuration to
generate authentication information for the DHCPREQUEST message.
Droms, Arbaugh [Page 9]
DRAFT Authentication for DHCP Messages March 2000
If client receives no DHCPACK messages or none of the DHCPACK
messages pass validation, the client behaves as if it had not
received a DHCPACK message in section 4.4.5 of the DHCP
specification [1].
5.5.4 REBINDING state
When in REBINDING state, the client uses the secret it used in its
initial DHCPREQUEST message to obtain its current configuration to
generate authentication information for the DHCPREQUEST message.
If client receives no DHCPACK messages or none of the DHCPACK
messages pass validation, the client behaves as if it had not
received a DHCPACK message in section 4.4.5 of the DHCP
specification [1].
5.5.5 DHCPINFORM message
Since the client already has some configuration information, the
client may also have established a shared secret value, K, with a
server. Therefore, the client SHOULD use the authentication
request as in a DHCPDISCOVER message when a shared secret value
exists. The client MUST treat any received DHCPACK messages as it
does DHCPOFFER messages, see section 5.5.1.
5.5.6 DHCPRELEASE message
Since the client is already in the BOUND state, the client will
have a security association already established with the server.
Therefore, the client MUST include authentication information with
the DHCPRELEASE message.
5.6 Server considerations
This section describes the behavior of a server in response to
client messages using authentication protocol 1.
5.6.1 General considerations
Each server maintains a list of secrets and identifiers for those
secrets that it shares with clients and potential clients. This
information must be maintained in such a way that the server can:
* Identify an appropriate secret and the identifier for that
secret for use with a client that the server may not have
previously communicated with
* Retrieve the secret and identifier used by a client to which the
server has provided previous configuration information
Droms, Arbaugh [Page 10]
DRAFT Authentication for DHCP Messages March 2000
Each server MUST save the counter from the previous authenticated
message. A server MUST discard any incoming message which fails
the replay detection check as defined by the RDM avoid replay
attacks.
DISCUSSION:
The authenticated DHCPREQUEST message from a client in INIT-
REBOOT state can only be validated by servers that used the
same secret in their DHCPOFFER messages. Other servers will
discard the DHCPREQUEST messages. Thus, only servers that used
the secret selected by the client will be able to determine
that their offered configuration information was not selected
and the offered network address can be returned to the server's
pool of available addresses. The servers that cannot validate
the DHCPREQUEST message will eventually return their offered
network addresses to their pool of available addresses as
described in section 3.1 of the DHCP specification [1].
5.6.2 After receiving a DHCPDISCOVER message
The server selects a secret for the client and includes
authentication information in the DHCPOFFER message as specified
in section 5, above. The server MUST record the identifier of the
secret selected for the client and use that same secret for
validating subsequent messages with the client.
5.6.3 After receiving a DHCPREQUEST message
The server uses the secret identified in the message and validates
the message as specified in section 5.3. If the message fails to
pass validation or the server does not know the secret identified
by the 'secret ID' field, the server MUST discard the message and
MAY choose to log the validation failure.
If the message passes the validation procedure, the server
responds as described in the DHCP specification. The server MUST
include authentication information generated as specified in
section 5.2.
5.6.4 After receiving a DHCPINFORM message
The server MAY choose to accept unauthenticated DHCPINFORM
messages, or only accept authenticated DHCPINFORM messages based
on a site policy.
When a client includes the authentication request in a DHCPINFORM
message, the server MUST respond with an authenticated DHCPACK
Droms, Arbaugh [Page 11]
DRAFT Authentication for DHCP Messages March 2000
message. If the server does not have a shared secret value
established with the sender of the DHCPINFORM message, then the
server MAY respond with an unauthenticated DHCPACK message, or a
DHCPNAK if the server does not accept unauthenticated clients
based on the site policy, or the server MAY choose not to respond
to the DHCPINFORM message.
6. IANA Considerations
The author of a new DHCP authentication protocol, algorithm or
replay detection method will follow these steps to obtain
acceptance of the new procedure as a part of the DHCP Internet
Standard:
1. The author devises the new authentication protocol, algorithm
or replay detection method.
2. The author documents the new technique as an Internet Draft.
The protocol, algorithm or RDM code for any new procedure is
left as "To Be Determined" (TBD).
3. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official
Protocol Standards" (STD 1).
4. The new protocol progresses through the IETF standards process;
the specification of the new protocol 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. If the option is accepted as a Standard, the
specification for the option is published as a separate RFC.
5. At the time of acceptance as a Proposed Internet Standard and
publication as an RFC, IANA assigns a DHCP authentication
protocol number to the new protocol.
This procedure for defining new authentication protocols will
ensure that:
* allocation of new protocol numbers is coordinated from a single
authority,
* new protocols are reviewed for technical correctness and
appropriateness, and
* documentation for new protocols is complete and published.
DISCUSSION:
This procedure is patterned after the procedure for acceptance
of new DHCP options.
7. References
Droms, Arbaugh [Page 12]
DRAFT Authentication for DHCP Messages March 2000
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997.
[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," RFC-2104, February 1997.
[4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
1992.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC-2219, March 1997.
[6] Henry, M., "DHCP Option 61 UUID Type Definition,"
<draft-henry-DHCP-opt61-UUID-type-00.txt> (work in
progress, November 1998.
[7] Patrick, M., "DHCP Relay Agent Information Option,"
<draft-ietf-dhc-agent-options-05.txt> (work in progress),
November 1998.
[8] Gupta, V., "Flexible Authentication for DHCP Messages,"
<draft-gupta-dhcp-auth-00.txt> (work in progress, June
1998.
8. Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1995. The
editor 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.
The "delayed authentication" mechanism used in section 5 is due to
Bill Arbaugh. The threat model and requirements in sections 1.1
and 1.2 come from Bill's negotiation protocol proposal. The
attendees of an interim meeting of the DHC WG held in June, 1998,
including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill
Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan,
Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike
Dooley, Greg Rabil and Arun Kapur, developed the threat model and
reviewed several alternative proposals.
The replay detection method field is due to Vipul Gupta [8].
Droms, Arbaugh [Page 13]
DRAFT Authentication for DHCP Messages March 2000
Other input from Bill Sommerfield is gratefully acknowledged.
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
Narten for reviewing earlier drafts of this document.
9. Security considerations
This document describes authentication and verification mechanisms
for DHCP.
10. Editors' addresses
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Bill Arbaugh
Department of Computer Science
University of Maryland
A.V. Williams Building
College Park, MD 20742
Phone: (301) 455-2774
Email: waa@cs.umd.edu
10. Expiration
This document will expire on December 31, 2000.
Droms, Arbaugh [Page 14]
DRAFT Authentication for DHCP Messages March 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Droms, Arbaugh [Page 15]
DRAFT Authentication for DHCP Messages March 2000
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 [6],
subnet address, e.g. 192.168.1.0), which must be unique to that
client. That is, K = MAC(MK, unique-id), where MK is a secret master
key and MAC is a keyed one-way function such as HMAC-MD5.
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.
To avoid compromis of this key management system, the master key, MK,
MUST NOT be stored by any clients. The client SHOULD only be given
its key, K. If MK is compromised, a new MK SHOULD be chosen and all
clients given new individual keys.
Droms, Arbaugh [Page 16]