draft-ietf-dhc-authentication-06.txt   draft-ietf-dhc-authentication-07.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-05.txt June 1998 Obsoletes: draft-ietf-dhc-authentication-06.txt August 1998
Expires December 1998 Expires February 1999
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-06.txt> <draft-ietf-dhc-authentication-07.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
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.''
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast).
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] provides a The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts. constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for Additionally, some network administrators may wish to provide for
authentication of the source and contents of DHCP messages. This authentication of the source and contents of DHCP messages. This
document defines a new DHCP option through which authorization document defines a new DHCP option through which authorization
skipping to change at page 2, line 5 skipping to change at page 1, line 49
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.
DRAFT Authentication for DHCP Messages June 1998
Some network administrators may wish to provide authentication of the Some network administrators may wish to provide authentication of the
DRAFT Authentication for DHCP Messages August 1998
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
authentication and message authentication. authentication and message authentication.
1.1 Requirements DISCUSSION:
Throughout this document, the words that are used to define the This draft combines the original Schiller-Huitema-Droms
significance of particular requirements are capitalized. These words authentication mechanism (<draft-ietf-dhc-authentication-06.txt>)
are: with the "delayed authentication" proposal developed by Bill
Arbaugh. This draft has been published as a revision to <draft-
ietf-dhc-authentication-06.txt>.
o "MUST" 1.1 DHCP threat model
This word or the adjective "REQUIRED" means that the The threat to DHCP is inherently an insider threat (assuming a
item is an absolute requirement of this specification. properly configured network where BOOTP ports are blocked on the
enterprise's perimeter gateways.) Regardless of the gateway
configuration, however, the insider and outsider threats are the
same.
o "MUST NOT" The threat 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.
This phrase means that the item is an absolute prohibition The threat specific to a DHCP server is an invalid client
of this specification. 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.
o "SHOULD" The threat common to both the client and the server is the resource
"denial of service" attack. These attacks typically involve the
exhaustion of valid addresses, or the exhaustion of CPU or network
bandwidth.
This word or the adjective "RECOMMENDED" means that there 1.2 Design goals
may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
o "SHOULD NOT" These are the goals that were used in the development of the
authentication protocol, listed in order of importance:
This phrase means that there may exist valid reasons in DRAFT Authentication for DHCP Messages August 1998
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
DRAFT Authentication for DHCP Messages June 1998 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 breads design and implementation
errors).
o "MAY" 1.3 Requirements Terminology
This word or the adjective "OPTIONAL" means that this item is The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
truly optional. One vendor may choose to include the item "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
because a particular marketplace requires it or because it document are to be interpreted as described in RFC 2119 [5].
enhances the product, for example; another vendor may omit the
same item.
1.2 Terminology 1.4 DHCP Terminology
This document uses the following terms: This document uses the following terms:
o "DHCP client" o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP server" o "DHCP server"
skipping to change at page 3, line 50 skipping to change at page 4, line 5
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 reserved for future use. Other protocols may be defined according to
the procedure described in section 5. the procedure described in section 5.
DRAFT Authentication for DHCP Messages August 1998
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
DRAFT Authentication for DHCP Messages June 1998
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) ...
+----------+----------+----------+-----------+------ +----------+----------+----------+-----------+------
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
skipping to change at page 4, line 36 skipping to change at page 4, line 39
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.
4. Protocol 1 4. Protocol 1
If the protocol field is 1, the authentication information contains If the protocol field is 1, the message is using the "delayed
an encrypted value generated by the source as a message authentication" mechanism. In delayed authentication, the client
authentication code (MAC) to provide message authentication and requests authentication in its DHCPDISCOVER message and the server
entity authentication. replies with a DHCPOFFER message that includes authentication
information information. This authentication information contains an
encrypted value generated by the source as a message authentication
code (MAC) to provide message authentication and entity
authentication.
This technique is based on the HMAC protocol [3] using the MD5 hash This technique is based on the HMAC protocol [3] using the MD5 hash
{2]. {2].
DRAFT Authentication for DHCP Messages June 1998 DRAFT Authentication for DHCP Messages August 1998
4.1 Format 4.1 Format
The format of the authentication request in a DHCPDISCOVER message
for protocol 1 is:
+----------+----------+----------+
| Code | 1 | 1 |
+----------+----------+----------+
The format of the authentication information for protocol 1 is: The format of the authentication information for protocol 1 is:
+----------+----------+----------+ +----------+----------+----------+
| Code | n | 1 | | Code | n | 1 |
+----------+----------+----------+
| secret ID |
+----------+----------+----------+----------+- +----------+----------+----------+----------+-
| Counter (8 octets) ... | counter (8 octets) ...
+----------+----------+----------+----------+- +----------+----------+----------+----------+-
| MAC ... | MAC ...
+----------+----------+----------+----------+- +----------+----------+----------+----------+-
The following definitions will be used in the description of the The following definitions will be used in the description of the
authentication information for protocol 1: authentication information for protocol 1:
K - a secret value shared between the source and destination K - a secret value shared between the source and destination
of the message of the message; each secret has a unique identifier
Counter - the value of a 64-bit monotonically increasing counter Counter - the value of a 64-bit monotonically increasing counter
HMAC-MD5 - the MAC generating function as defined by [3] and [2] HMAC-MD5 - the MAC generating function as defined by [3] and [2]
The sender computes the MAC as described in [3]. The 'counter' field The sender computes the MAC as described in [3]. The 'secret ID'
of the authentication option MUST be set to the value of a field MUST be set to the identifier of the secret used to generate
monotonically increasing counter and the 'MAC' field of the the MAC. The 'counter' field of the authentication option MUST be
authentication option MUST be set to all 0s for the computation of set to the value of a monotonically increasing counter and the 'MAC'
the MAC. Because a DHCP relay agent may alter the values of the field of the authentication option MUST be set to all 0s for the
'giaddr' and 'hops' fields in the DHCP message, the contents of those computation of the MAC. Because a DHCP relay agent may alter the
two fields MUST also be set to zero for the computation of the values of the 'giaddr' and 'hops' fields in the DHCP message, the
message digest. Using a counter value such as the current time of contents of those two fields MUST also be set to zero for the
day (e.g., an NTP-format timestamp [4]) can reduce the danger of computation of the message digest. Using a counter value such as the
replay attacks. current time of day (e.g., an NTP-format timestamp [4]) can reduce
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 technique, such as HMAC-SHA, will be specified as a separate
protocol. protocol.
DRAFT Authentication for DHCP Messages August 1998
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. Therefore, protocol 1 may not scale well in an protocol. Each secret key has a unique identifier that can be
architecture in which a DHCP client may connect to multiple used by a receiver to determine which secret was used to generate
administrative domains. the MAC in the DHCP message. Therefore, protocol 1 may not scale
well in an architecture in which a DHCP client may connect to
multiple administrative domains.
Note that the meaning of an authentication option can be changed
by removing the secret ID, counter 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.
4.2 Message validation 4.2 Message validation
To validate an incoming message, the receiver checks the 'counter' To validate an incoming message, the receiver checks the 'counter'
field and computes the MAC as described in [3]. If the 'counter' field and computes the MAC as described in [3]. If the 'counter'
DRAFT Authentication for DHCP Messages June 1998
field does not contain a value larger than the last value of field does not contain a value larger than the last value of
'counter' used by the sender, the receiver MUST discard the incoming 'counter' used by the sender, the receiver MUST discard the incoming
message. The receiver MUST set the 'MAC' field of the authentication message. The receiver MUST set the 'MAC' field of the authentication
option to all 0s for computation of the MAC. Because a DHCP relay option to all 0s for computation of the MAC. Because a DHCP relay
agent may alter the values of the 'giaddr' and 'hops' fields in the 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 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 zero for the computation of the MAC. If the MAC computed by the
receiver does not match the MAC contained in the authentication receiver does not match the MAC contained in the authentication
option, the receiver MUST discard the DHCP message. option, the receiver MUST discard the DHCP message.
skipping to change at page 6, line 32 skipping to change at page 6, line 50
initially distributed to the client through some out-of-band initially distributed to the client through some out-of-band
mechanism, and must be stored locally on the client for use in all mechanism, and must be stored locally on the client for use in all
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.
Servers will be able to perform message authentication. To However, sharing of keys is strongly discouraged as it allows for
authenticate the identity of individual clients, each client must be unauthorized clients to masquerade as authorized clients by obtaining
configured with a unique key. Appendix A describes a technique for a copy of the shared key. Servers will be able to perform message
key management. 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
describes a technique for key management.
4.4 Client considerations
This section describes the behavior of a DHCP client using
authentication protocol 1.
4.4.1 INIT state
When in INIT state, the client uses protocol 1 as follows:
1. The client includes the authentication request option in its
DHCPDISCOVER message.
DISCUSSION:
Is the 'chaddr' field sufficient to identify the client or
should the client be required to include a 'client identifier'
option?
2. The client validates any DHCPOFFER messages that include
authentication information using the mechanism specified in
section 4.2. 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 includes
authentication information encoded with the same secret used by
the server in the selected DHCPOFFER message.
4. The client validates 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. The the DHCPACK
fails to pass validation, the client reverts 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.
4.4.2 INIT-REBOOT state
When in INIT-REBOOT state, the client uses the secret it used in its
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 reverts to INIT state.
DRAFT Authentication for DHCP Messages August 1998
4.4.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. 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].
4.4.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].
4.5 Server considerations
This section describes the behavior of a server in response to client
messages using authentication protocol 1.
4.5.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
Each server MUST save the counter from the previous authenticated
message. A server MUST discard any incoming message whose counter is
not strictly greater than the counter from the previous message to
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
DRAFT Authentication for DHCP Messages August 1998
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].
4.5.2 After receiving a DHCPDISCOVER message
The server selects a secret for the client and includes
authentication information generated by that secret as specified in
section 4.1. The server MUST record the secret selected for the
client and use that secret for validating subsequent messages with
the client.
4.5.3 After receiving a DHCPREQUEST message
The server uses the secret identified in the message and validates
the message as specified in section 4.2. If the message fails to
pass validation or the server does not know the secret identified by
the 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 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 protocol 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). The new protocol will be submitted for
eventual acceptance as an Internet Standard. 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 new option will be reviewed by the Dynamic Host Configuration
Working Group (if that group still exists), or as an Internet Working Group (if that group still exists), or as an Internet
Draft not submitted by an IETF working group. Draft not submitted by an IETF working group.
This procedure for defining new authentication protocols will ensure This procedure for defining new authentication protocols will ensure
that: that:
DRAFT Authentication for DHCP Messages June 1998
* new options are reviewed for technical correctness and * new options are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new options is complete and published. * documentation for new options is complete and published.
DRAFT Authentication for DHCP Messages August 1998
6. References 6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, October 1993. 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" <draft-ietf-ipsec-hmac-md5-01.txt> (work in Message Authentication," RFC-2104, February 1997.
progress), August 1996.
[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
Levels," RFC-2219, March 1997.
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
author 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.
Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for The "delayed authentication" mechanism used in section 4 is due to
reviewing this document, and to Thomas Narten for reviewing earlier William Arbaugh. The threat model and requirements in sections 1.1
drafts of this document. 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.
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
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. Author'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
DRAFT Authentication for DHCP Messages June 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 for To avoid centralized management of a list of random keys, suppose K
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.
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 known message from a new client by regenerating K from the client-id. For
clients, the server can choose to recover the client's K dynamically from known clients, the server can choose to recover the client's K
the client-id in the DHCP message, or can choose to precompute and cache dynamically from the client-id in the DHCP message, or can choose to
all of the Ks a priori. precompute and cache all of the Ks a priori.
 End of changes. 

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