draft-ietf-dhc-authentication-13.txt   draft-ietf-dhc-authentication-14.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-12.txt W. Arbaugh, Editor Obsoletes: draft-ietf-dhc-authentication-13.txt W. Arbaugh, Editor
University of Maryland University of Maryland
June 2000 July 2000
Expires December 2000 Expires December 2000
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-13.txt> <draft-ietf-dhc-authentication-14.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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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:
0 1 2 3 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 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 | | Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Replay Detection (64 bits) | | RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | | Replay cont. | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
DRAFT Authentication for DHCP Messages March 2000 DRAFT Authentication for DHCP Messages March 2000
| | | |
| Authentication Information | | Authentication Information |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 11 skipping to change at page 6, line 11
will be defined as separate protocols. will be defined as separate protocols.
5. Protocol 1 5. Protocol 1
DRAFT Authentication for DHCP Messages March 2000 DRAFT Authentication for DHCP Messages March 2000
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 a information. This authentication information contains a nonce value
nonce value generated by the source as a message authentication code generated by the source as a message authentication code (MAC) to
(MAC) to provide message authentication and entity authentication. 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].
5.1 Management Issues 5.1 Management Issues
The "delayed authentication" protocol does not attempt to address The "delayed authentication" protocol does not attempt to address
situations where a client may roam from one administrative domain to situations where a client may roam from one administrative domain to
another, i.e. interdomain roaming. This protocol is focused on another, i.e. interdomain roaming. This protocol is focused on
solving the intradomain problem where the out-of-band exchange of a solving the intradomain problem where the out-of-band exchange of a
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 connects to well in an architecture in which a DHCP client connects to
multiple administrative domains. multiple administrative domains.
DRAFT Authentication for DHCP Messages March 2000 DRAFT Authentication for DHCP Messages March 2000
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
this option can only appear in a DHCPDISCOVER message. this option can only appear in a DHCPDISCOVER message or a
DHCPINFORM message.
5.3 Message validation 5.3 Message validation
To validate an incoming message, the receiver first checks that To validate an incoming message, the receiver first checks that
the value in the replay detection field is acceptable according to the value in the replay detection field is acceptable according to
the replay detection method specified by the RDM field. Next, the the replay detection method specified by the RDM field. Next, the
receive computes the MAC as described in [3]. The receiver MUST receiver computes the MAC as described in [3]. The receiver MUST
set the 'MAC' field of the authentication option to all 0s for set the 'MAC' field of the authentication option to all 0s for
computation of the MAC, and because a DHCP relay agent may alter 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 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 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 computation of the MAC. If the MAC computed by the receiver does
not match the MAC contained in the authentication option, the not match the MAC contained in the authentication option, the
receiver MUST discard the DHCP message. receiver MUST discard the DHCP message.
Section 3 provides additional information on handling messages Section 3 provides additional information on handling messages
that include option 82 (Relay Agents). that include option 82 (Relay Agents).
skipping to change at page 8, line 54 skipping to change at page 9, line 5
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.
5.5 Client considerations 5.5 Client considerations
This section describes the behavior of a DHCP client using
DRAFT Authentication for DHCP Messages March 2000 DRAFT Authentication for DHCP Messages March 2000
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
its DHCPDISCOVER message along with option 61 [6] to identify its DHCPDISCOVER message along with option 61 [6] to identify
itself uniquely to the server. itself uniquely to the server.
skipping to change at page 9, line 54 skipping to change at page 10, line 4
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 section 3.2 of [1]. messages as specified in section 3.2 of [1].
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
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
DRAFT Authentication for DHCP Messages March 2000 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 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
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
skipping to change at page 10, line 54 skipping to change at page 11, line 5
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
server has provided previous configuration information server has provided previous configuration information
Each server MUST save the counter from the previous authenticated
DRAFT Authentication for DHCP Messages March 2000 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 message. A server MUST discard any incoming message which fails
the replay detection check as defined by the RDM avoid replay the replay detection check as defined by the RDM avoid replay
attacks. attacks.
DISCUSSION: DISCUSSION:
The authenticated DHCPREQUEST message from a client in INIT- The authenticated DHCPREQUEST message from a client in INIT-
REBOOT state can only be validated by servers that used the REBOOT state can only be validated by servers that used the
same secret in their DHCPOFFER messages. Other servers will same secret in their DHCPOFFER messages. Other servers will
discard the DHCPREQUEST messages. Thus, only servers that used discard the DHCPREQUEST messages. Thus, only servers that used
skipping to change at page 11, line 54 skipping to change at page 12, line 4
section 5.2. section 5.2.
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.
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
DRAFT Authentication for DHCP Messages March 2000 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 established with the sender of the DHCPINFORM message, then the
server MAY respond with an unauthenticated DHCPACK message, or a server MAY respond with an unauthenticated DHCPACK message, or a
DHCPNAK if the server does not accept unauthenticated clients DHCPNAK if the server does not accept unauthenticated clients
based on the site policy. based on the site policy, or the server MAY choose not to respond
to the DHCPINFORM message.
6. IANA Considerations 6. IANA Considerations
The author of a new DHCP authentication protocol, algorithm or The author of a new DHCP authentication protocol, algorithm or
replay detection method will follow these steps to obtain replay detection method will follow these steps to obtain
acceptance of the new procedure as a part of the DHCP Internet acceptance of the new procedure as a part of the DHCP Internet
Standard: Standard:
1. The author devises the new authentication protocol, algorithm 1. The author devises the new authentication protocol, algorithm
or replay detection method. or replay detection method.
skipping to change at page 12, line 52 skipping to change at page 13, line 5
* new protocols are reviewed for technical correctness and * new protocols are reviewed for technical correctness and
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.
7. References 7. References
DRAFT Authentication for DHCP Messages March 2000
[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.
DRAFT Authentication for DHCP Messages March 2000
[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.
[4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
1992. 1992.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 13, line 52 skipping to change at page 14, line 5
and 1.2 come from Bill's negotiation protocol proposal. The 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,
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.
The replay detection method field is due to Vipul Gupta [8]. The replay detection method field is due to Vipul Gupta [8].
DRAFT Authentication for DHCP Messages March 2000
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
DRAFT Authentication for DHCP Messages March 2000
Narten for reviewing earlier drafts of this document. Narten for reviewing earlier drafts of this document.
9. Security considerations 9. Security considerations
This document describes authentication and verification mechanisms This document describes authentication and verification mechanisms
for DHCP. for DHCP.
10. Editors' addresses 10. Editors' addresses
Ralph Droms Ralph Droms
skipping to change at line 715 skipping to change at page 16, line 21
subnet address, e.g. 192.168.1.0), which must be unique to that 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 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. key and MAC is a keyed one-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
generate its own key K. The server can quickly validate an incoming 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 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 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 dynamically from the client-id in the DHCP message, or can choose to
precompute and cache all of the Ks a priori. 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.
 End of changes. 

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