draft-ietf-dhc-authentication-07.txt   draft-ietf-dhc-authentication-08.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-06.txt August 1998 Obsoletes: draft-ietf-dhc-authentication-07.txt W. Arbaugh, Editor
University of Pennsylvania
August 1998
Expires February 1999 Expires February 1999
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-07.txt> <draft-ietf-dhc-authentication-08.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 49 skipping to change at page 2, line 5
DHCP server. DHCP server.
1. 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.
Some network administrators may wish to provide authentication of the
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
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
medium is not physically secured, such as wireless networks or medium is not physically secured, such as wireless networks or
college residence halls. college residence halls.
This document defines a technique that can provide both entity This document defines a technique that can provide both entity
skipping to change at page 2, line 54 skipping to change at page 3, line 4
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" attack. These attacks typically involve the "denial of service" attack. These attacks typically involve the
exhaustion of valid addresses, or the exhaustion of CPU or network exhaustion of valid addresses, or the exhaustion of CPU or network
bandwidth. bandwidth.
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:
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
authentication protocol, listed in order of importance:
1. Address the threats presented in Section 1.1. 1. Address the threats presented in Section 1.1.
2. Avoid changing the current protocol. 2. Avoid changing the current protocol.
3. Limit state required by the server. 3. Limit state required by the server.
4. Limit complexity (complexity breads design and implementation 4. Limit complexity (complexity breads design and implementation
errors). errors).
1.3 Requirements Terminology 1.3 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
skipping to change at page 3, line 51 skipping to change at page 4, line 4
| Authentication information ... | 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 and authentication information contains the length of the protocol and authentication information
fields in octets. The protocol field defines the particular fields in octets. The protocol field defines the particular
technique for authentication used in the option. technique for authentication used in the option.
This document defines two protocols in sections 3 and 4, encoded with This document defines two protocols in sections 3 and 4, 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
reserved for future use. Other protocols may be defined according to
the procedure described in section 5.
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
reserved for future use. Other protocols may be defined according to
the procedure described in section 5.
3. Protocol 0 3. 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:
+----------+----------+----------+ +----------+----------+----------+
| Code | n+1 | 0 | | Code | n+1 | 0 |
+----------+----------+----------+-----------+------ +----------+----------+----------+-----------+------
| Authentication token (n octets) ... | Authentication token (n octets) ...
+----------+----------+----------+-----------+------ +----------+----------+----------+-----------+------
skipping to change at page 4, line 49 skipping to change at page 5, line 4
If the protocol field is 1, the message is using the "delayed If the protocol field is 1, the message is using the "delayed
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 an information information. This authentication information contains an
encrypted value generated by the source as a message authentication encrypted value generated by the source as a message authentication
code (MAC) to provide message authentication and entity code (MAC) to provide message authentication and entity
authentication. authentication.
This technique is based on the HMAC protocol [3] using the MD5 hash This technique is based on the HMAC protocol [3] using the MD5 hash
{2].
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
{2].
4.1 Format 4.1 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:
+----------+----------+----------+ +----------+----------+----------+
| Code | 1 | 1 | | Code | 1 | 1 |
+----------+----------+----------+ +----------+----------+----------+
The format of the authentication information for protocol 1 is: The format of the authentication information for protocol 1 is:
skipping to change at page 5, line 51 skipping to change at page 6, line 4
computation of the MAC. Because a DHCP relay agent may alter 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 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 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 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 current time of day (e.g., an NTP-format timestamp [4]) can reduce
the danger of replay attacks. the danger of replay attacks.
DISCUSSION: DISCUSSION:
Protocol 1 specifies the use of HMAC-MD5. Use of a different Protocol 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate
protocol.
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
technique, such as HMAC-SHA, will be specified as a separate
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
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, counter and MAC, transforming an by removing the secret ID, counter and MAC, transforming an
skipping to change at page 6, line 52 skipping to change at page 7, line 4
authenticated DHCP messages. Once the client has been given its key, authenticated DHCP messages. Once the client has been given its key,
it may use that key for all transactions even if the client's 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 configuration changes; e.g., if the client is assigned a new network
address. address.
Each DHCP server must know the keys for all authorized clients. If Each DHCP server must know the keys for all authorized clients. If
all clients use the same key, clients can perform both entity and all clients use the same key, clients can perform both entity and
message authentication for all messages received from servers. message authentication for all messages received from servers.
However, sharing of keys is strongly discouraged as it allows for However, sharing of keys is strongly discouraged as it allows for
unauthorized clients to masquerade as authorized clients by obtaining unauthorized clients to masquerade as authorized clients by obtaining
a copy of the shared key. 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
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
a copy of the shared key. 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. describes a technique for key management.
4.4 Client considerations 4.4 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.
4.4.1 INIT state 4.4.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:
skipping to change at page 7, line 52 skipping to change at page 8, line 4
fails to pass validation, the client reverts to INIT state and fails to pass validation, the client reverts to INIT state and
returns to step 1. The client MAY choose to remember which server returns to step 1. The client MAY choose to remember which server
replied with a DHCPACK message that failed to pass validation and replied with a DHCPACK message that failed to pass validation and
discard subsequent messages from that server. discard subsequent messages from that server.
4.4.2 INIT-REBOOT state 4.4.2 INIT-REBOOT state
When in INIT-REBOOT state, the client uses the secret it used in its When in INIT-REBOOT state, the client uses the secret it used in its
DHCPREQUEST message to obtain its current configuration to generate DHCPREQUEST message to obtain its current configuration to generate
authentication information for the DHCPREQUEST message. If client authentication information for the DHCPREQUEST message. If client
receives no DHCPACK messages or none of the DHCPACK messages pass
validation, the client reverts to INIT state.
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
receives no DHCPACK messages or none of the DHCPACK messages pass
validation, the client reverts to INIT state.
4.4.3 RENEWING state 4.4.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
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. If generate authentication information for the DHCPREQUEST message. If
client receives no DHCPACK messages or none of the DHCPACK messages client receives no DHCPACK messages or none of the DHCPACK messages
pass validation, the client behaves as if it had not received a pass validation, the client behaves as if it had not received a
DHCPACK message in section 4.4.5 of the DHCP specification [1]. DHCPACK message in section 4.4.5 of the DHCP specification [1].
4.4.4 REBINDING state 4.4.4 REBINDING state
skipping to change at page 8, line 52 skipping to change at page 9, line 4
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 is message. A server MUST discard any incoming message whose counter is
not strictly greater than the counter from the previous message to not strictly greater than the counter from the previous message to
avoid replay attacks. avoid replay attacks.
DISCUSSION: DISCUSSION:
The authenticated DHCPREQUEST message from a client in INIT-REBOOT The authenticated DHCPREQUEST message from a client in INIT-REBOOT
state can only be validated by servers that used the same secret state can only be validated by servers that used the same secret
in their DHCPOFFER messages. Other servers will discard the 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
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
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 network address can be returned to the server's pool of available
addresses. The servers that cannot validate the DHCPREQUEST addresses. The servers that cannot validate the DHCPREQUEST
message will eventually return their offered network addresses to message will eventually return their offered network addresses to
their pool of available addresses as described in section 3.1 of their pool of available addresses as described in section 3.1 of
the DHCP specification [1]. the DHCP specification [1].
4.5.2 After receiving a DHCPDISCOVER message 4.5.2 After receiving a DHCPDISCOVER message
The server selects a secret for the client and includes The server selects a secret for the client and includes
authentication information generated by that secret as specified in authentication information generated by that secret as specified in
skipping to change at page 9, line 38 skipping to change at page 9, line 41
If the message passes the validation procedure, the server responds If the message passes the validation procedure, the server responds
as described in the DHCP specification. The server MUST include as described in the DHCP specification. The server MUST include
authentication information generated as specified in section 4.1. authentication information generated as specified in section 4.1.
5. Definition of new authentication protocols 5. Definition of new authentication protocols
The author of a new DHCP option will follow these steps to obtain The author of a new DHCP option will follow these steps to obtain
acceptance of the protocol as a part of the DHCP Internet Standard: acceptance of the protocol as a part of the DHCP Internet Standard:
1. The author devises the new authentication protocol. 1. The author devises the new authentication protocol.
2. The author documents the new protocol as an Internet Draft. 2. The author documents the new authentication protocol, leaving the
option code as "To Be Determined" (TBD), as an Internet Draft.
3. The author submits the Internet Draft for review through the IETF 3. The author submits the Internet Draft for review through the IETF
standards process as defined in "Internet Official Protocol standards process as defined in "Internet Official Protocol
Standards" (STD 1). The new protocol will be submitted for Standards" (STD 1).
eventual acceptance as an Internet Standard.
4. The new protocol progresses through the IETF standards process; 4. The new protocol progresses through the IETF standards process;
the new option will be reviewed by the Dynamic Host Configuration the specification of the new protocol will be reviewed by the
Working Group (if that group still exists), or as an Internet Dynamic Host Configuration Working Group (if that group still
Draft not submitted by an IETF working group. exists), or as an Internet Draft not submitted by an IETF working
group. If the options is accepted as a Standard, the
specification for the option is published as a separate RFC.
5. At the time of acceptance as an Internet Standard and publication
as an RFC, IANA assigns a DHCP authentication protocol number to
the new protocol.
DRAFT Authentication for DHCP Messages August 1998
This procedure for defining new authentication protocols will ensure This procedure for defining new authentication protocols will ensure
that: that:
* new options are reviewed for technical correctness and * allocation of new protocol numbers is coordinated from a single
authority,
* new protocols are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new options is complete and published. * documentation for new protocols is complete and published.
DRAFT Authentication for DHCP Messages August 1998 DISCUSSION:
This procedure is patterned after the procedure for acceptance of
new DHCP options.
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
skipping to change at page 10, line 39 skipping to change at page 11, line 4
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 1.1 William Arbaugh. The threat model and requirements in sections 1.1
and 1.2 come from Bill's negotiation protocol proposal. The attendees 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 of an interim meeting of the DHC WG held in June, 1998, including
Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh,
Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah,
DRAFT Authentication for DHCP Messages August 1998
Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg
Rabil and Arun Kapur, developed the threat model and reviewed several Rabil and Arun Kapur, developed the threat model and reviewed several
alternative proposals. alternative proposals.
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.
9. Editor's address 9. Editor's address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
DRAFT Authentication for DHCP Messages August 1998
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 EMail: droms@bucknell.edu
William Arbaugh
University of Pennsylvania
Philadelphia, PA
Phone: (410) 465-3432
EMail: waa@dsl.cis.upenn.edu
Expiration
This document will expire on February 2, 1999.
DRAFT Authentication for DHCP Messages August 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
DRAFT Authentication for DHCP Messages August 1998 DRAFT Authentication for DHCP Messages August 1998
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 = MD5(MK, 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 unique-id), where MK is a secret master key and MD5 is some encoding
function. function.
 End of changes. 

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