draft-ietf-dhc-authentication-03.txt   draft-ietf-dhc-authentication-04.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-02.txt November 1996 Obsoletes: draft-ietf-dhc-authentication-03.txt August 1997
Expires May 1997 Expires February 1997
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-03.txt> <draft-ietf-dhc-authentication-04.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 2, line 5 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.
DRAFT Authentication for DHCP Messages November 1996 DRAFT Authentication for DHCP Messages August 1997
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
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.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
the case carefully weighed before choosing a different course. the case carefully weighed before choosing a different course.
o "SHOULD NOT" o "SHOULD NOT"
This phrase means that there may exist valid reasons in This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior and the case carefully weighed before implementing any behavior
described with this label. described with this label.
DRAFT Authentication for DHCP Messages November 1996 DRAFT Authentication for DHCP Messages August 1997
o "MAY" o "MAY"
This word or the adjective "OPTIONAL" means that this item is This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the enhances the product, for example; another vendor may omit the
same item. same item.
1.2 Terminology 1.2 Terminology
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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.
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 November 1996 DRAFT Authentication for DHCP Messages August 1997
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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
4. Protocol 1 4. Protocol 1
If the protocol field is 1, the authentication information contains If the protocol field is 1, the authentication information contains
an encrypted value generated by the source as a message an encrypted value generated by the source as a message
authentication code (MAC) to provide message authentication and authentication code (MAC) to provide message authentication and
entity authentication. 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 November 1996 DRAFT Authentication for DHCP Messages August 1997
4.1 Format 4.1 Format
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 |
+----------+----------+----------+----------+- +----------+----------+----------+----------+-
| Counter (8 octets) ... | Counter (8 octets) ...
+----------+----------+----------+----------+- +----------+----------+----------+----------+-
skipping to change at page 5, line 44 skipping to change at page 5, line 44
message digest. Using a counter value such as the current time of message digest. Using a counter value such as the current time of
day (e.g., an NTP-format timestamp [4]) can reduce the danger of day (e.g., an NTP-format timestamp [4]) can reduce the danger of
replay attacks. 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.
Protocol 1 requires a shared secret key for each client on each
DHCP server with which that client may wish to use the DHCP
protocol. Therefore, protocol 1 may not scale well in an
architecture in which a DHCP client may connect to multiple
administrative domains.
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 August 1997
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
DRAFT Authentication for DHCP Messages November 1996
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.
4.3 Key utilization 4.3 Key utilization
Each DHCP client has a key, K. The client uses its key to encode any 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 must be messages it receives from the server. The client's key must be
initially distributed to the client through some out-of-band initially distributed to the client through some out-of-band
skipping to change at page 6, line 34 skipping to change at page 6, line 40
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 Servers will be able to perform message authentication. To
authenticate the identity of individual clients, each client must be authenticate the identity of individual clients, each client must be
configured with a unique key. Appendix A describes a technique for configured with a unique key. Appendix A describes a technique for
key management. key management.
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 option 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 August 1997
* 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 November 1996
6. References 6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993. Bucknell University, October 1993.
[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" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
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 November 1996 DRAFT Authentication for DHCP Messages August 1997
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 for
each client is generated from the pair (client identifier, subnet 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
 End of changes. 

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