draft-ietf-dhc-authentication-11.txt   draft-ietf-dhc-authentication-12.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-11.txt W. Arbaugh, Editor Obsoletes: draft-ietf-dhc-authentication-11.txt W. Arbaugh, Editor
University of Pennsylvania University of Pennsylvania
June 1999 October 1999
Expires December 1999 Expires June 1999
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-11.txt> <draft-ietf-dhc-authentication-12.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. 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
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt, and the list of http://www.ietf.org/ietf/1id-abstracts.txt, and the list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network. for passing configuration information to hosts on a TCP/IP network.
In some situations, network administrators may wish to constrain the In some situations, network administrators may wish to constrain the
allocation of addresses to authorized hosts. Additionally, some allocation of addresses to authorized hosts. Additionally, some
skipping to change at page 2, line 5 skipping to change at page 2, line 5
generated and newly attached hosts with proper authorization can be generated and newly attached hosts with proper authorization can be
automatically configured from an authenticated DHCP server. automatically configured from an authenticated DHCP server.
1. Introduction 1. Introduction
DHCP [1] transports protocol stack configuration parameters from DHCP [1] 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
DRAFT Authentication for DHCP Messages June 1999 DRAFT Authentication for DHCP Messages October 1999
a manual step in configuration of TCP/IP hosts. a manual step in configuration of TCP/IP hosts.
Some network administrators may wish to provide authentication of the Some network administrators may wish to provide authentication of the
source and contents of DHCP messages. For example, clients may be source and contents of DHCP messages. For example, clients may be
subject to denial of service attacks through the use of bogus DHCP subject to denial of service attacks through the use of bogus DHCP
servers, or may simply be misconfigured due to unintentionally servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network denial of service attacks in "hostile" environments where the network
skipping to change at page 3, line 5 skipping to change at page 3, line 5
with unintentionally incorrect configuration parameters. with unintentionally incorrect configuration parameters.
The threat specific to a DHCP server is an invalid client The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of "theft of service", or to circumvent auditing for any number of
nefarious purposes. nefarious purposes.
The threat common to both the client and the server is the resource The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve the "denial of service" (DoS) attack. These attacks typically involve the
DRAFT Authentication for DHCP Messages June 1999 DRAFT Authentication for DHCP Messages October 1999
exhaustion of valid addresses, or the exhaustion of CPU or network exhaustion of valid addresses, or the exhaustion of CPU or network
bandwidth, and are present anytime there is a shared resource. In bandwidth, and are present anytime there is a shared resource. In
current practice, redundancy mitigates DoS attacks the best. current practice, redundancy mitigates DoS attacks the best.
1.2 Design goals 1.2 Design goals
These are the goals that were used in the development of the These are the goals that were used in the development of the
authentication protocol, listed in order of importance: authentication protocol, listed in order of importance:
skipping to change at page 4, line 5 skipping to change at page 4, line 5
o "DHCP server" o "DHCP server"
A DHCP server of "server"is an Internet host that returns A DHCP server of "server"is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
2. Format of the authentication option 2. Format of the authentication option
The following diagram defines the format of the DHCP The following diagram defines the format of the DHCP
authentication option: authentication option:
DRAFT Authentication for DHCP Messages June 1999 DRAFT Authentication for DHCP Messages October 1999
+----------+----------+----------+-----------+ 0 1 2 3
| Code | Length | Protocol | Algorithm | 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
+----------+----------+----------+-----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Replay Counter ... | Code | Length | Protocol (2) |RDM| Algorithm |
+----------+----------+----------+-----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication information ... | |
+----------+----------+----------+-----------+- + Replay Detection (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| Authentication Information ...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the authentication option is TBD, and the length field The code for the authentication option is TBD, and the length field
contains the length of the protocol, algorithm and authentication contains the length of the protocol, RDM, algorithm, Replay Detection
information fields in octets. The protocol field defines the fields and authentication information fields in octets.
particular technique for authentication used in the option. The
algorithm field defines the specific algorithm with the technique The protocol field defines the particular technique for
identified by the protocol field. The global replay counter field of authentication used in the option. New protocols are defined as
the authentication option MUST be set to the value of a monotonically decribed in Section 6.
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 The Replay Detection Method (RDM) bit field determines the type of
replay attacks. replay detection used in the Replay Detection Field. The following
defines the possible values for the RDM:
00 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.
01 Reserved to be defined as described in Section 6.
10 Reserved to be defined as described in Section 6.
11 Reserved to be 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.
This document defines two protocols in sections 4 and 5, encoded with This document defines two protocols in sections 4 and 5, encoded with
protocol field values 0 and 1. Protocol field values 2-254 are protocol field values 0 and 1. Protocol field values 2-254 are
DRAFT Authentication for DHCP Messages October 1999
reserved for future use. Other protocols may be defined according to reserved for future use. Other protocols may be defined according to
the procedure described in section 6. the procedure described in section 6.
3. Interaction with Relay Agents 3. Interaction with Relay Agents
Because a DHCP relay agent may alter the values of the 'giaddr' 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 '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 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 message header. Additionally, a relay agent may append the DHCP relay
agent information option 82 [7] as the last option in a message to agent information option 82 [7] as the last option in a message to
skipping to change at page 5, line 5 skipping to change at page 5, line 29
included in the message without changing the order of options. If the included in the message without changing the order of options. If the
server understands option 82 and will echo the option back to the server understands option 82 and will echo the option back to the
relay agent, the server MUST not include the option in the relay agent, the server MUST not include the option in the
computation of any hash function over the message. computation of any hash function over the message.
4. Protocol 0 4. Protocol 0
If the protocol field is 0, the authentication information field If the protocol field is 0, the authentication information field
holds a simple authentication token: holds a simple authentication token:
DRAFT Authentication for DHCP Messages June 1999 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 | n+1 | 0 | 0 | | Code | Length |0 0 0 0 0 0 0 0|0 0|0 0 0 0 0 0|
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Replay Counter ... | |
+----------+----------+----------+----------+- + Replay Detection (64 bits) +
| Authentication token (n octets) ... | |
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication token (n octets) ... +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication token is an opaque, unencoded value known to both The authentication token is an opaque, unencoded value known to both
the sender and receiver. The sender inserts the authentication token the sender and receiver. The sender inserts the authentication token
in the DHCP message and the receiver matches the token from the in the DHCP message and the receiver matches the token from the
message to the shared token. If the authentication option is present message to the shared token. If the authentication option is present
and the token from the message does not match the shared token, the and the token from the message does not match the shared token, the
receiver MUST discard the message. receiver MUST discard the message.
Protocol 0 may be used to pass a plain-text password and provides Protocol 0 may be used to pass a plain-text password and provides
only weak entity authentication and no message authentication. This only weak entity authentication and no message authentication. This
DRAFT Authentication for DHCP Messages October 1999
protocol is only useful for rudimentary protection against protocol is only useful for rudimentary protection against
inadvertently instantiated DHCP servers. inadvertently instantiated DHCP servers.
DISCUSSION: DISCUSSION:
The intent here is to pass a constant, non-computed token such as The intent here is to pass a constant, non-computed token such as
a plain-text password. Other types of entity authentication using a plain-text password. Other types of entity authentication using
computed tokens such as Kerberos tickets or one-time passwords computed tokens such as Kerberos tickets or one-time passwords
will be defined as separate protocols. will be defined as separate protocols.
skipping to change at page 6, line 5 skipping to change at page 6, line 30
authentication" mechanism. In delayed authentication, the client authentication" mechanism. In delayed authentication, the client
requests authentication in its DHCPDISCOVER message and the server requests authentication in its DHCPDISCOVER message and the server
replies with a DHCPOFFER message that includes authentication replies with a DHCPOFFER message that includes authentication
information information. This authentication information contains a information information. This authentication information contains a
nonce value generated by the source as a message authentication code nonce value generated by the source as a message authentication code
(MAC) to provide message authentication and entity authentication. (MAC) to provide message authentication and entity authentication.
This document defines the use of a particular technique based on the This document defines the use of a particular technique based on the
HMAC protocol [3] using the MD5 hash [2]. HMAC protocol [3] using the MD5 hash [2].
DRAFT Authentication for DHCP Messages June 1999
5.1 Management Issues 5.1 Management Issues
This protocol does not attempt to address situations where a client This protocol does not attempt to address situations where a client
may roam from one administrative domain to another, i.e. interdomain may roam from one administrative domain to another, i.e. interdomain
roaming. This protocol is focused solving the intradomain problem roaming. This protocol is focused solving the intradomain problem
where the out-of-band exchange of a shared secret is feasible. where the out-of-band exchange of a shared secret is feasible.
5.2 Format 5.2 Format
The format of the authentication request in a DHCPDISCOVER message The format of the authentication request in a DHCPDISCOVER message
for protocol 1 is: for protocol 1 is:
+----------+----------+----------+----------+ 0 1 2 3
| Code | 2 | 1 | Algorithm| 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
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Replay Counter ... | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm |
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Replay Detection (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DRAFT Authentication for DHCP Messages October 1999
The format of the authentication information for protocol 1 is: The format of the authentication information for protocol 1 is:
+----------+----------+----------+----------+ 0 1 2 3
| Code | n | 1 | Algorithm| 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
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Replay Counter ... | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm |
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Replay Detection (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret ID | | secret ID |
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... | HMAC-MD5 ...
+----------+----------+----------+----------+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines one technique for use with protocol 1, which is This document defines one technique for use with protocol 1, which is
identified by setting the algorithm field to 1. Other techniques identified by setting the algorithm field to 1. Other techniques
that use different algorithms may be defined by future that use different algorithms may be defined by future
specifications, see section 6. The following definitions will be specifications, see section 6. The following definitions will be
used in the description of the authentication information for used in the description of the authentication information for
protocol 1, algorithm 1: protocol 1, algorithm 1:
Global Replay Counter - the value of a 64-bit monotonically Replay Detection - as defined by the RDM field
increasing counter
K - a secret value shared between the source and K - a secret value shared between the source and
destination of the message; each secret has a destination of the message; each secret has a
unique identifier unique identifier (not shown in figures)
secret ID - the unique identifier for the secret value secret ID - the unique identifier for the secret value
used to generate the MAC for this message used to generate the MAC for this message
HMAC-MD5 - the MAC generating function [3, 2]. HMAC-MD5 - the MAC generating function [3, 2].
DRAFT Authentication for DHCP Messages June 1999
The sender computes the MAC using the HMAC generation algorithm [3] The sender computes the MAC using the HMAC generation algorithm [3]
and the MD5 hash function [2]. The entire DHCP message (except as and the MD5 hash function [2]. The entire DHCP message (except as
noted below), including the DHCP message header and the options noted below), including the DHCP message header and the options
field, is used as input to the HMAC-MD5 computation function. The 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 'secret ID' field MUST be set to the identifier of the secret used to
generate the MAC. generate the MAC.
DISCUSSION: DISCUSSION:
Algorithm 1 specifies the use of HMAC-MD5. Use of a different Algorithm 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate technique, such as HMAC-SHA, will be specified as a separate
protocol. protocol.
Protocol 1 requires a shared secret key for each client on each Protocol 1 requires a shared secret key for each client on each
DHCP server with which that client may wish to use the DHCP DHCP server with which that client may wish to use the DHCP
DRAFT Authentication for DHCP Messages October 1999
protocol. Each secret key has a unique identifier that can be protocol. Each secret key has a unique identifier that can be
used by a receiver to determine which secret was used to generate used by a receiver to determine which secret was used to generate
the MAC in the DHCP message. Therefore, protocol 1 may not scale the MAC in the DHCP message. Therefore, protocol 1 may not scale
well in an architecture in which a DHCP client may connect to well in an architecture in which a DHCP client may connect to
multiple administrative domains. multiple administrative domains.
Note that the meaning of an authentication option can be changed Note that the meaning of an authentication option can be changed
by removing the secret ID, and MAC, transforming an authentication by removing the secret ID, and MAC, transforming an authentication
option with authentication information into a request for option with authentication information into a request for
authentication. Therefore, the authentication request form of authentication. Therefore, the authentication request form of
skipping to change at page 8, line 4 skipping to change at page 8, line 40
the MAC computed by the receiver does not match the MAC contained the MAC computed by the receiver does not match the MAC contained
in the authentication option, the receiver MUST discard the DHCP in the authentication option, the receiver MUST discard the DHCP
message. message.
5.4 Key utilization 5.4 Key utilization
Each DHCP client has a key, K. The client uses its key to encode 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 sends to the server and to authenticate and verify
any messages it receives from the server. The client's key SHOULD any messages it receives from the server. The client's key SHOULD
be initially distributed to the client through some out-of-band be initially distributed to the client through some out-of-band
DRAFT Authentication for DHCP Messages June 1999
mechanism, and SHOULD be stored locally on the client for use in mechanism, and SHOULD be stored locally on the client for use in
all authenticated DHCP messages. Once the client has been given all authenticated DHCP messages. Once the client has been given
its key, it SHOULD use that key for all transactions even if the 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 client's configuration changes; e.g., if the client is assigned a
new network address. new network address.
Each DHCP server MUST know, or be able to obtain in a secure Each DHCP server MUST know, or be able to obtain in a secure
manner, the keys for all authorized clients. If all clients use manner, the keys for all authorized clients. If all clients use
the same key, clients can perform both entity and message the same key, clients can perform both entity and message
authentication for all messages received from servers. However, authentication for all messages received from servers. However,
the sharing of keys is strongly discouraged as it allows for the sharing of keys is strongly discouraged as it allows for
unauthorized clients to masquerade as authorized clients by unauthorized clients to masquerade as authorized clients by
obtaining a copy of the shared key. To authenticate the identity obtaining a copy of the shared key. To authenticate the identity
of individual clients, each client MUST be configured with a of individual clients, each client MUST be configured with a
unique key. Appendix A describes a technique for key management. unique key. Appendix A describes a technique for key management.
DRAFT Authentication for DHCP Messages October 1999
5.5 Client considerations 5.5 Client considerations
This section describes the behavior of a DHCP client using This section describes the behavior of a DHCP client using
authentication protocol 1. authentication protocol 1.
5.5.1 INIT state 5.5.1 INIT state
When in INIT state, the client uses protocol 1 as follows: When in INIT state, the client uses protocol 1 as follows:
1. The client MUST include the authentication request option in 1. The client MUST include the authentication request option in
skipping to change at page 9, line 4 skipping to change at page 9, line 39
reject unauthenticated DHCPOFFER messages. reject unauthenticated DHCPOFFER messages.
3. The client replies with a DHCPREQUEST message that MUST include 3. The client replies with a DHCPREQUEST message that MUST include
authentication information encoded with the same secret used by authentication information encoded with the same secret used by
the server in the selected DHCPOFFER message. the server in the selected DHCPOFFER message.
4. The client MUST validate the DHCPACK message from the server. 4. The client MUST validate the DHCPACK message from the server.
The client MUST discard the DHCPACK if the message fails to The client MUST discard the DHCPACK if the message fails to
pass validation and MAY log the validation failure. If the pass validation and MAY log the validation failure. If the
DHCPACK fails to pass validation, the client MUST revert to DHCPACK fails to pass validation, the client MUST revert to
INIT state and returns to step 1. The client MAY choose to INIT state and returns to step 1. The client MAY choose to
remember which server replied with a DHCPACK message that remember which server replied with a DHCPACK message that
DRAFT Authentication for DHCP Messages June 1999
failed to pass validation and discard subsequent messages from failed to pass validation and discard subsequent messages from
that server. that server.
5.5.2 INIT-REBOOT state 5.5.2 INIT-REBOOT state
When in INIT-REBOOT state, the client MUST use the secret it used When in INIT-REBOOT state, the client MUST use the secret it used
in its DHCPREQUEST message to obtain its current configuration to in its DHCPREQUEST message to obtain its current configuration to
generate authentication information for the DHCPREQUEST message. generate authentication information for the DHCPREQUEST message.
The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK
messages if no authenticated messages were received. The client messages if no authenticated messages were received. The client
MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
messages as specified in RFC 2131, section 3.2. messages as specified in RFC 2131, section 3.2.
5.5.3 RENEWING state 5.5.3 RENEWING state
When in RENEWING state, the client uses the secret it used in its When in RENEWING state, the client uses the secret it used in its
DRAFT Authentication for DHCP Messages October 1999
initial DHCPREQUEST message to obtain its current configuration to initial DHCPREQUEST message to obtain its current configuration to
generate authentication information for the DHCPREQUEST message. generate authentication information for the DHCPREQUEST message.
If client receives no DHCPACK messages or none of the DHCPACK If client receives no DHCPACK messages or none of the DHCPACK
messages pass validation, the client behaves as if it had not messages pass validation, the client behaves as if it had not
received a DHCPACK message in section 4.4.5 of the DHCP received a DHCPACK message in section 4.4.5 of the DHCP
specification [1]. specification [1].
5.5.4 REBINDING state 5.5.4 REBINDING state
When in REBINDING state, the client uses the secret it used in its When in REBINDING state, the client uses the secret it used in its
skipping to change at page 9, line 49 skipping to change at page 10, line 33
5.5.5 DHCPINFORM message 5.5.5 DHCPINFORM message
Since the client already has some configuration information, the Since the client already has some configuration information, the
client may also have established a shared secret value, K, with a client may also have established a shared secret value, K, with a
server. Therefore, the client SHOULD use the authentication server. Therefore, the client SHOULD use the authentication
request as in a DHCPDISCOVER message when a shared secret value request as in a DHCPDISCOVER message when a shared secret value
exists. The client MUST treat any received DHCPACK messages as it exists. The client MUST treat any received DHCPACK messages as it
does DHCPOFFER messages, see section 5.5.1. 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 5.6 Server considerations
This section describes the behavior of a server in response to This section describes the behavior of a server in response to
client messages using authentication protocol 1. client messages using authentication protocol 1.
5.6.1 General considerations 5.6.1 General considerations
DRAFT Authentication for DHCP Messages June 1999
Each server maintains a list of secrets and identifiers for those Each server maintains a list of secrets and identifiers for those
secrets that it shares with clients and potential clients. This secrets that it shares with clients and potential clients. This
information must be maintained in such a way that the server can: information must be maintained in such a way that the server can:
* Identify an appropriate secret and the identifier for that * Identify an appropriate secret and the identifier for that
secret for use with a client that the server may not have secret for use with a client that the server may not have
previously communicated with previously communicated with
* Retrieve the secret and identifier used by a client to which the * Retrieve the secret and identifier used by a client to which the
DRAFT Authentication for DHCP Messages October 1999
server has provided previous configuration information server has provided previous configuration information
Each server MUST save the counter from the previous authenticated Each server MUST save the counter from the previous authenticated
message. A server MUST discard any incoming message whose counter message. A server MUST discard any incoming message whose counter
is not strictly greater than the counter from the previous message is not strictly greater than the counter from the previous message
to avoid replay attacks. to avoid replay attacks.
DISCUSSION: DISCUSSION:
The authenticated DHCPREQUEST message from a client in INIT- The authenticated DHCPREQUEST message from a client in INIT-
skipping to change at page 11, line 4 skipping to change at page 11, line 47
The server uses the secret identified in the message and validates The server uses the secret identified in the message and validates
the message as specified in section 4.2. If the message fails to the message as specified in section 4.2. If the message fails to
pass validation or the server does not know the secret identified pass validation or the server does not know the secret identified
by the 'secret ID' field, the server MUST discard the message and by the 'secret ID' field, the server MUST discard the message and
MAY choose to log the validation failure. MAY choose to log the validation failure.
If the message passes the validation procedure, the server If the message passes the validation procedure, the server
responds as described in the DHCP specification. The server MUST responds as described in the DHCP specification. The server MUST
include authentication information generated as specified in include authentication information generated as specified in
DRAFT Authentication for DHCP Messages June 1999
section 4.1. section 4.1.
5.6.4 After receiving a DHCPINFORM message 5.6.4 After receiving a DHCPINFORM message
The server MAY choose to accept unauthenticated DHCPINFORM The server MAY choose to accept unauthenticated DHCPINFORM
messages, or only accept authenticated DHCPINFORM messages based messages, or only accept authenticated DHCPINFORM messages based
on a site policy. on a site policy.
DRAFT Authentication for DHCP Messages October 1999
When a client includes the authentication request in a DHCPINFORM When a client includes the authentication request in a DHCPINFORM
message, the server MUST respond with an authenticated DHCPACK message, the server MUST respond with an authenticated DHCPACK
message. If the server does not have a shared secret value message. If the server does not have a shared secret value
established with the sender of the DHCPINFORM message, then the established with the sender of the DHCPINFORM message, then the
server can either respond with an unauthenticated DHCPACK message, server can either respond with an unauthenticated DHCPACK message,
or a DHCPNACK if the server does not accept unauthenticated or a DHCPNACK if the server does not accept unauthenticated
clients. clients.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 12, line 4 skipping to change at page 12, line 47
5. At the time of acceptance as an Internet Standard and 5. At the time of acceptance as an Internet Standard and
publication as an RFC, IANA assigns a DHCP authentication publication as an RFC, IANA assigns a DHCP authentication
protocol number to the new protocol. protocol number to the new protocol.
This procedure for defining new authentication protocols will This procedure for defining new authentication protocols will
ensure that: ensure that:
* allocation of new protocol numbers is coordinated from a single * allocation of new protocol numbers is coordinated from a single
authority, authority,
* new protocols are reviewed for technical correctness and * new protocols are reviewed for technical correctness and
DRAFT Authentication for DHCP Messages June 1999
appropriateness, and appropriateness, and
* documentation for new protocols is complete and published. * documentation for new protocols is complete and published.
DISCUSSION: DISCUSSION:
This procedure is patterned after the procedure for acceptance This procedure is patterned after the procedure for acceptance
of new DHCP options. of new DHCP options.
DRAFT Authentication for DHCP Messages October 1999
6. References 6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997. Bucknell University, March 1997.
[2] Rivest, R., "The MD5 Message-Digest Algorithm", [2] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992. RFC-1321, April 1992.
[3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC-2104, February 1997. Message Authentication," RFC-2104, February 1997.
skipping to change at page 12, line 39 skipping to change at page 13, line 32
Levels," RFC-2219, March 1997. Levels," RFC-2219, March 1997.
[6] Henry, M., "DHCP Option 61 UUID Type Definition," [6] Henry, M., "DHCP Option 61 UUID Type Definition,"
<draft-henry-DHCP-opt61-UUID-type-00.txt> (work in <draft-henry-DHCP-opt61-UUID-type-00.txt> (work in
progress, November 1998. progress, November 1998.
[7] Patrick, M., "DHCP Relay Agent Information Option," [7] Patrick, M., "DHCP Relay Agent Information Option,"
<draft-ietf-dhc-agent-options-05.txt> (work in progress), <draft-ietf-dhc-agent-options-05.txt> (work in progress),
November 1998. November 1998.
[8] Gupta, V., "Flexible Authentication for DHCP Messages,"
<draft-gupta-dhcp-auth-00.txt> (work in progress, June
1998.
7. Acknowledgments 7. Acknowledgments
Jeff Schiller and Christian Huitema developed this scheme during a Jeff Schiller and Christian Huitema developed this scheme during a
terminal room BOF at the Dallas IETF meeting, December 1995. The terminal room BOF at the Dallas IETF meeting, December 1995. The
editor transcribed the notes from that discussion, which form the editor transcribed the notes from that discussion, which form the
basis for this document. The editor appreciates Jeff's and basis for this document. The editor appreciates Jeff's and
Christian's patience in reviewing this document and its earlier Christian's patience in reviewing this document and its earlier
drafts. drafts.
The "delayed authentication" mechanism used in section 4 is due to The "delayed authentication" mechanism used in section 4 is due to
William Arbaugh. The threat model and requirements in sections William Arbaugh. The threat model and requirements in sections
1.1 and 1.2 come from Bill's negotiation protocol proposal. The 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, attendees of an interim meeting of the DHC WG held in June, 1998,
including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill
Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan,
DRAFT Authentication for DHCP Messages June 1999
Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike
Dooley, Greg Rabil and Arun Kapur, developed the threat model and Dooley, Greg Rabil and Arun Kapur, developed the threat model and
reviewed several alternative proposals. reviewed several alternative proposals.
DRAFT Authentication for DHCP Messages October 1999
The replay detection method field is due to Vipul Gupta [8].
Other input from Bill Sommerfield is gratefully acknowledged. Other input from Bill Sommerfield is gratefully acknowledged.
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
Narten for reviewing earlier drafts of this document. Narten for reviewing earlier drafts of this document.
8. Security considerations 8. Security considerations
This document describes authentication and verification mechanisms This document describes authentication and verification mechanisms
for DHCP. for DHCP.
skipping to change at page 13, line 40 skipping to change at page 14, line 38
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
William Arbaugh William Arbaugh
University of Pennsylvania University of Pennsylvania
Philadelphia, PA Philadelphia, PA
EMail: waa@dsl.cis.upenn.edu EMail: waa@dsl.cis.upenn.edu
10. Expiration 10. Expiration
This document will expire on December 31, 1999. This document will expire on June 30, 2000.
DRAFT Authentication for DHCP Messages June 1999 DRAFT Authentication for DHCP Messages October 1999
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
skipping to change at page 15, line 5 skipping to change at page 16, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
DRAFT Authentication for DHCP Messages June 1999 DRAFT Authentication for DHCP Messages October 1999
Appendix A - Key Management Technique Appendix A - Key Management Technique
To avoid centralized management of a list of random keys, suppose K To avoid centralized management of a list of random keys, suppose K
for each client is generated from the pair (client identifier, subnet for each client is generated from the pair (client identifier, subnet
address), which must be unique to that client. That is, K = MAC(MK, address), 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- unique-id), where MK is a secret master key and MAC is a keyed one-
way function such as HMAC-MD5. way function such as HMAC-MD5.
Without knowledge of the master key MK, an unauthorized client cannot Without knowledge of the master key MK, an unauthorized client cannot
 End of changes. 

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