draft-ietf-dhc-authentication-15.txt   rfc3118.txt 
Network Working Group R. Droms, Editor Network Working Group R. Droms, Editor
INTERNET DRAFT Bucknell University Request for Comments: 3118 Cisco Systems
Obsoletes: draft-ietf-dhc-authentication-15.txt W. Arbaugh, Editor Category: Standards Track W. Arbaugh, Editor
University of Maryland University of Maryland
November 2000 June 2001
Expires May 2001
Authentication for DHCP Messages Authentication for DHCP Messages
<draft-ietf-dhc-authentication-15.txt>
Status of this memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/ietf/1id-abstracts.txt, and the list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework This document defines a new Dynamic Host Configuration Protocol
for passing configuration information to hosts on a TCP/IP network. (DHCP) option through which authorization tickets can be easily
In some situations, network administrators may wish to constrain the
allocation of addresses to authorized hosts. Additionally, some
network administrators may wish to provide for authentication of the
source and contents of DHCP messages. This document defines a new
DHCP option through which authorization tickets can be easily
generated and newly attached hosts with proper authorization can be generated and newly attached hosts with proper authorization can be
automatically configured from an authenticated DHCP server. automatically configured from an authenticated DHCP server. DHCP
provides a framework for passing configuration information to hosts
on a TCP/IP network. In some situations, network administrators may
wish to constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
authentication of the source and contents of DHCP messages.
1. Introduction 1. Introduction
DHCP [1] transports protocol stack configuration parameters from DHCP [1] transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating dynamically allocate addresses from a pool of addresses, eliminating
DRAFT Authentication for DHCP Messages November 2000
a manual step in configuration of TCP/IP hosts. a manual step in configuration of TCP/IP hosts.
Some network administrators may wish to provide authentication of the Some network administrators may wish to provide authentication of the
source and contents of DHCP messages. For example, clients may be source and contents of DHCP messages. For example, clients may be
subject to denial of service attacks through the use of bogus DHCP subject to denial of service attacks through the use of bogus DHCP
servers, or may simply be misconfigured due to unintentionally servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network denial of service attacks in "hostile" environments where the network
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. The current protocol authentication and message authentication. The current protocol
combines the original Schiller-Huitema-Droms authentication mechanism combines the original Schiller-Huitema-Droms authentication mechanism
defined in a previous Internet Draft with the "delayed defined in a previous work in progress with the "delayed
authentication" proposal developed by Bill Arbaugh. authentication" proposal developed by Bill Arbaugh.
1.1 DHCP threat model 1.1 DHCP threat model
The threat to DHCP is inherently an insider threat (assuming a The threat to DHCP is inherently an insider threat (assuming a
properly configured network where BOOTP ports are blocked on the properly configured network where BOOTP ports are blocked on the
enterprise's perimeter gateways.) Regardless of the gateway enterprise's perimeter gateways.) Regardless of the gateway
configuration, however, the potential attacks by insiders and configuration, however, the potential attacks by insiders and
outsiders are the same. outsiders are the same.
The attack specific to a DHCP client is the possibility of the The attack specific to a DHCP client is the possibility of the
establishment of a "rogue" server with the intent of providing establishment of a "rogue" server with the intent of providing
incorrect configuration information to the client. The motivation for incorrect configuration information to the client. The motivation
doing so may be to establish a "man in the middle" attack or it may for doing so may be to establish a "man in the middle" attack or it
be for a "denial of service" attack. may be for a "denial of service" attack.
There is another threat to DHCP clients from mistakenly or There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters. with unintentionally incorrect configuration parameters.
The threat specific to a DHCP server is an invalid client The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of "theft of service", or to circumvent auditing for any number of
nefarious purposes. nefarious purposes.
The threat common to both the client and the server is the resource The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve the "denial of service" (DoS) attack. These attacks typically involve
exhaustion of valid addresses, or the exhaustion of CPU or network the exhaustion of valid addresses, or the exhaustion of CPU or
bandwidth, and are present anytime there is a shared resource. In network bandwidth, and are present anytime there is a shared
current practice, redundancy mitigates DoS attacks the best. resource. In current practice, redundancy mitigates DoS attacks the
best.
DRAFT Authentication for DHCP Messages November 2000
1.2 Design goals 1.2 Design goals
These are the goals that were used in the development of the These are the goals that were used in the development of the
authentication protocol, listed in order of importance: authentication protocol, listed in order of importance:
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 breeds design and implementation 4. Limit complexity (complexity breeds 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
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in RFC 2119 [5].
skipping to change at page 3, line 30 skipping to change at page 3, line 21
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
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in RFC 2119 [5].
1.4 DHCP 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
configuration parameters such as a network address. obtain configuration parameters such as a network address.
o "DHCP server" o "DHCP server"
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
DRAFT Authentication for DHCP Messages November 2000
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
authentication option: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) | | RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | | Replay cont. | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Authentication Information | | Authentication Information |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the authentication option is TBD, and the length field The code for the authentication option is 90, and the length field
contains the length of the protocol, RDM, algorithm, Replay Detection contains the length of the protocol, RDM, algorithm, Replay Detection
fields and authentication information fields in octets. fields and authentication information fields in octets.
The protocol field defines the particular technique for The protocol field defines the particular technique for
authentication used in the option. New protocols are defined as authentication used in the option. New protocols are defined as
described in Section 6. described in Section 6.
The algorithm field defines the specific algorithm within the The algorithm field defines the specific algorithm within the
technique identified by the protocol field. technique identified by the protocol field.
skipping to change at page 5, line 5 skipping to change at page 4, line 24
The Replay Detection Method (RDM) field determines the type of replay The Replay Detection Method (RDM) field determines the type of replay
detection used in the Replay Detection field. detection used in the Replay Detection field.
If the RDM field contains 0x00, the replay detection field MUST be If the RDM field contains 0x00, the replay detection field MUST be
set to the value of a monotonically increasing counter. Using a set to the value of a monotonically increasing counter. Using a
counter value such as the current time of day (e.g., an NTP-format counter value such as the current time of day (e.g., an NTP-format
timestamp [4]) can reduce the danger of replay attacks. This method timestamp [4]) can reduce the danger of replay attacks. This method
MUST be supported by all protocols. MUST be supported by all protocols.
DRAFT Authentication for DHCP Messages November 2000
3. Interaction with Relay Agents 3. Interaction with Relay Agents
Because a DHCP relay agent may alter the values of the 'giaddr' and Because a DHCP relay agent may alter the values of the 'giaddr' and
'hops' fields in the DHCP message, the contents of those two fields 'hops' fields in the DHCP message, the contents of those two fields
MUST be set to zero for the computation of any hash function over the MUST be set to zero for the computation of any hash function over the
message header. Additionally, a relay agent may append the DHCP relay message header. Additionally, a relay agent may append the DHCP
agent information option 82 [7] as the last option in a message to relay agent information option 82 [7] as the last option in a message
servers. If a server finds option 82 included in a received message, the to servers. If a server finds option 82 included in a received
server MUST compute any hash function as if the option were NOT included message, the server MUST compute any hash function as if the option
in the message without changing the order of options. Whenever the were NOT included in the message without changing the order of
server sends back option 82 to a relay agent, the server MUST not options. Whenever the server sends back option 82 to a relay agent,
include the option in the computation of any hash function over the the server MUST not include the option in the computation of any hash
message. function over the message.
4. Protocol 0 4. Configuration token
If the protocol field is 0, the authentication information field holds a If the protocol field is 0, the authentication information field
simple authentication token: holds a simple configuration token:
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 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| | Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Replay Detection (64 bits) | |0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | | Replay cont. | |
|-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+ |
| | | |
| Authentication Information | | Authentication Information |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication token is an opaque, unencoded value known to both the The configuration token is an opaque, unencoded value known to both
sender and receiver. The sender inserts the authentication token in the the sender and receiver. The sender inserts the configuration token
DHCP message and the receiver matches the token from the message to the in the DHCP message and the receiver matches the token from the
shared token. If the authentication option is present and the token message to the shared token. If the configuration option is present
from the message does not match the shared token, the receiver MUST and the token from the message does not match the shared token, the
discard the message. receiver MUST discard the message.
Protocol 0 may be used to pass a plain-text password and provides only
weak entity authentication and no message authentication. This protocol
is only useful for rudimentary protection against inadvertently
DRAFT Authentication for DHCP Messages November 2000
instantiated DHCP servers. Configuration token may be used to pass a plain-text configuration
token and provides only weak entity authentication and no message
authentication. This protocol is only useful for rudimentary
protection against inadvertently instantiated DHCP servers.
DISCUSSION: DISCUSSION:
The intent here is to pass a constant, non-computed token such as a The intent here is to pass a constant, non-computed token such as
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 will computed tokens such as Kerberos tickets or one-time passwords
be defined as separate protocols. will be defined as separate protocols.
5. Protocol 1 5. Delayed authentication
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. This authentication information contains a nonce value information. This authentication information contains a nonce value
generated by the source as a message authentication code (MAC) to generated by the source as a message authentication code (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 solving another, i.e., interdomain roaming. This protocol is focused on
the intradomain problem where the out-of-band exchange of a shared solving the intradomain problem where the out-of-band exchange of a
secret is feasible. shared secret is feasible.
DRAFT Authentication for DHCP Messages November 2000
5.2 Format 5.2 Format
The format of the authentication request in a DHCPDISCOVER or a The format of the authentication request in a DHCPDISCOVER or a
DHCPINFORM message for protocol 1 is: DHCPINFORM message for delayed authentication is:
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 |0 0 0 0 0 0 0 1| Algorithm | | Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) | | RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | Replay cont. |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The format of the authentication information in a DHCPOFFER, DHCPREQUEST The format of the authentication information in a DHCPOFFER,
or DHCPACK message for protocol 1 is: DHCPREQUEST or DHCPACK message for delayed authentication is:
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 |0 0 0 0 0 0 0 1| Algorithm | | Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) | | RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | | Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Secret ID (32 bits) | | Replay cont. | Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret id cont| HMAC-MD5 (128 bits) .... | secret id cont| HMAC-MD5 (128 bits) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, algorithm 1: authentication information for delayed authentication, algorithm 1:
Replay Detection - as defined by the RDM field Replay Detection - as defined by the RDM field
K - a secret value shared between the source and K - a secret value shared between the source and
destination of the message; each secret has a destination of the message; each secret has a
unique identifier (secret ID) unique identifier (secret ID)
secret ID - the unique identifier for the secret value secret ID - the unique identifier for the secret value
used to generate the MAC for this message used to generate the MAC for this message
HMAC-MD5 - the MAC generating function [3, 2]. HMAC-MD5 - the MAC generating function [3, 2].
DRAFT Authentication for DHCP Messages November 2000 The sender computes the MAC using the HMAC generation algorithm [3]
and the MD5 hash function [2]. The entire DHCP message (except as
The sender computes the MAC using the HMAC generation algorithm [3] and noted below), including the DHCP message header and the options
the MD5 hash function [2]. The entire DHCP message (except as noted field, is used as input to the HMAC-MD5 computation function. The
below), including the DHCP message header and the options field, is used 'secret ID' field MUST be set to the identifier of the secret used to
as input to the HMAC-MD5 computation function. The 'secret ID' field generate the MAC.
MUST be set to the identifier of the secret used to generate the MAC.
DISCUSSION: DISCUSSION:
Algorithm 1 specifies the use of HMAC-MD5. Use of a different Algorithm 1 specifies the use of HMAC-MD5. Use of a different
technique, such as HMAC-SHA, will be specified as a separate technique, such as HMAC-SHA, will be specified as a separate
protocol. protocol.
Protocol 1 requires a shared secret key for each client on each DHCP Delayed authentication requires a shared secret key for each
server with which that client may wish to use the DHCP protocol. client on each DHCP server with which that client may wish to use
Each secret key has a unique identifier that can be used by a the DHCP protocol. Each secret key has a unique identifier that
receiver to determine which secret was used to generate the MAC in can be used by a receiver to determine which secret was used to
the DHCP message. Therefore, protocol 1 may not scale well in an generate the MAC in the DHCP message. Therefore, delayed
architecture in which a DHCP client connects to multiple authentication may not scale well in an architecture in which a
administrative domains. DHCP client connects to multiple administrative domains.
5.3 Message validation 5.3 Message validation
To validate an incoming message, the receiver first checks that the 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 replay detection method specified by the RDM field. Next, the
receiver computes the MAC as described in [3]. The receiver MUST set receiver computes the MAC as described in [3]. The receiver MUST set
the 'MAC' field of the authentication option to all 0s for the 'MAC' field of the authentication option to all 0s for
computation of the MAC, and because a DHCP relay agent may alter the 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
skipping to change at page 9, line 5 skipping to change at page 8, line 17
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 SHOULD be messages it receives from the server. The client's key SHOULD be
initially distributed to the client through some out-of-band initially distributed to the client through some out-of-band
mechanism, and SHOULD be stored locally on the client for use in all mechanism, and SHOULD 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 SHOULD use that key for all transactions even if the client's it SHOULD 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.
DRAFT Authentication for DHCP Messages November 2000
Each DHCP server MUST know, or be able to obtain in a secure manner, Each DHCP server MUST know, or be able to obtain in a secure manner,
the keys for all authorized clients. If all clients use the same the keys for all authorized clients. If all clients use the same
key, clients can perform both entity and message authentication for key, clients can perform both entity and message authentication for
all messages received from servers. However, the sharing of keys is all messages received from servers. However, the sharing of keys is
strongly discouraged as it allows for unauthorized clients to strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a copy of the shared masquerade as authorized clients by obtaining a copy of the shared
key. To authenticate the identity of individual clients, each client key. To authenticate the identity of individual clients, each client
MUST be configured with a unique key. Appendix A describes a MUST be configured with a unique key. Appendix A describes a
technique for key management. technique for key management.
5.5 Client considerations 5.5 Client considerations
This section describes the behavior of a DHCP client using This section describes the behavior of a DHCP client using delayed
authentication protocol 1. authentication.
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 delayed authentication as
follows:
1. The client MUST include the authentication request option in its 1. The client MUST include the authentication request option in its
DHCPDISCOVER message along with a client identifier option [6] to DHCPDISCOVER message along with a client identifier option [6] to
identify itself uniquely to the server. identify itself uniquely to the server.
2. The client MUST perform the validation test described in section 2. The client MUST perform the validation test described in section
5.3 on any DHCPOFFER messages that include authentication 5.3 on any DHCPOFFER messages that include authentication
information. If one or more DHCPOFFER messages pass the information. If one or more DHCPOFFER messages pass the
validation test, the client chooses one of the offered validation test, the client chooses one of the offered
configurations. configurations.
skipping to change at page 10, line 4 skipping to change at page 9, line 17
DHCPOFFER message can make the client vulnerable to spoofing and DHCPOFFER message can make the client vulnerable to spoofing and
other attacks. If local users are not explicitly informed that other attacks. If local users are not explicitly informed that
the client has accepted an unauthenticated DHCPOFFER message, the the client has accepted an unauthenticated DHCPOFFER message, the
users may incorrectly assume that the client has received an users may incorrectly assume that the client has received an
authenticated address and is not subject to DHCP attacks through authenticated address and is not subject to DHCP attacks through
unauthenticated messages. unauthenticated messages.
A client MUST be configurable to decline unauthenticated messages, A client MUST be configurable to decline unauthenticated messages,
and SHOULD be configured by default to decline unauthenticated and SHOULD be configured by default to decline unauthenticated
messages. A client MAY choose to differentiate between DHCPOFFER messages. A client MAY choose to differentiate between DHCPOFFER
DRAFT Authentication for DHCP Messages November 2000
messages with no authentication information and DHCPOFFER messages messages with no authentication information and DHCPOFFER messages
that do not pass the validation test; for example, a client might that do not pass the validation test; for example, a client might
accept the former and discard the latter. If a client does accept accept the former and discard the latter. If a client does accept
an unauthenticated message, the client SHOULD inform any local an unauthenticated message, the client SHOULD inform any local
users and SHOULD log the event. users and SHOULD log the event.
3. The client replies with a DHCPREQUEST message that MUST include 3. The client replies with a DHCPREQUEST message that MUST include
authentication information encoded with the same secret used by authentication information encoded with the same secret used by
the server in the selected DHCPOFFER message. the server in the selected DHCPOFFER message.
skipping to change at page 11, line 4 skipping to change at page 10, line 19
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].
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. If generate authentication information for the DHCPREQUEST message. If
DRAFT Authentication for DHCP Messages November 2000
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].
5.5.5 DHCPINFORM message 5.5.5 DHCPINFORM message
Since the client already has some configuration information, the Since the client already has some configuration information, the
client may also have established a shared secret value, K, with a client may also have established a shared secret value, K, with a
server. Therefore, the client SHOULD use the authentication request server. Therefore, the client SHOULD use the authentication request
as in a DHCPDISCOVER message when a shared secret value exists. The as in a DHCPDISCOVER message when a shared secret value exists. The
skipping to change at page 11, line 30 skipping to change at page 10, line 42
5.5.6 DHCPRELEASE message 5.5.6 DHCPRELEASE message
Since the client is already in the BOUND state, the client will have Since the client is already in the BOUND state, the client will have
a security association already established with the server. a security association already established with the server.
Therefore, the client MUST include authentication information with Therefore, the client MUST include authentication information with
the DHCPRELEASE message. the DHCPRELEASE message.
5.6 Server considerations 5.6 Server considerations
This section describes the behavior of a server in response to client This section describes the behavior of a server in response to client
messages using authentication protocol 1. messages using delayed authentication.
5.6.1 General considerations 5.6.1 General considerations
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 secret * Identify an appropriate secret and the identifier for that secret
for use with a client that the server may not have previously for use with a client that the server may not have previously
communicated with communicated with
skipping to change at page 12, line 4 skipping to change at page 11, line 18
message. A server MUST discard any incoming message which fails the message. A server MUST discard any incoming message which fails the
replay detection check as defined by the RDM avoid replay attacks. replay detection check as defined by the RDM 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 DHCPREQUEST messages. Thus, only servers that used the secret
selected by the client will be able to determine that their selected by the client will be able to determine that their
DRAFT Authentication for DHCP Messages November 2000
offered configuration information was not selected and the offered 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].
5.6.2 After receiving a DHCPDISCOVER message 5.6.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 in the DHCPOFFER message as specified in authentication information in the DHCPOFFER message as specified in
section 5, above. The server MUST record the identifier of the secret section 5, above. The server MUST record the identifier of the
selected for the client and use that same secret for validating secret selected for the client and use that same secret for
subsequent messages with the client. validating subsequent messages with the client.
5.6.3 After receiving a DHCPREQUEST message 5.6.3 After receiving a DHCPREQUEST message
The server uses the secret identified in the message and validates The server uses the secret identified in the message and validates
the message as specified in section 5.3. If the message fails to the message as specified in section 5.3. If the message fails to
pass validation or the server does not know the secret identified by pass validation or the server does not know the secret identified by
the 'secret ID' field, the server MUST discard the message and MAY the 'secret ID' field, the server MUST discard the message and MAY
choose to log the validation failure. choose to log the validation failure.
If the message passes the validation procedure, the server responds If the message passes the validation procedure, the server responds
skipping to change at page 12, line 51 skipping to change at page 12, line 16
message, the server MUST respond with an authenticated DHCPACK message, the server MUST respond with an authenticated DHCPACK
message. If the server does not have a shared secret value message. If the server does not have a shared secret value
established with the sender of the DHCPINFORM message, then the established with the sender of the DHCPINFORM message, then the
server 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 based DHCPNAK if the server does not accept unauthenticated clients based
on the site policy, or the server MAY choose not to respond to the on the site policy, or the server MAY choose not to respond to the
DHCPINFORM message. DHCPINFORM message.
6. IANA Considerations 6. IANA Considerations
This document defines two protocols, encoded with protocol field Section 2 defines a new DHCP option called the Authentication Option,
values 0 and 1, an algorithm for protocol 1 and a replay detection whose option code is 90.
method encoded with RDM field value 0. Other protocols, algorithms
and replay detection methods may be defined in subsequent documents.
DRAFT Authentication for DHCP Messages November 2000
The author of a new DHCP authentication protocol, algorithm or replay This document specifies three new name spaces associated with the
detection method will follow these steps to obtain acceptance of the Authentication Option, which are to be created and maintained by
new procedure as a part of the DHCP Internet Standard: IANA: Protocol, Algorithm and RDM.
1. The author devises the new authentication protocol, algorithm or Initial values assigned from the Protocol name space are 0 (for the
replay detection method. configuration token Protocol in section 4) and 1 (for the delayed
2. The author documents the new technique as an Internet Draft. The authentication Protocol in section 5). Additional values from the
protocol, algorithm or RDM code for any new procedure is left as Protocol name space will be assigned through IETF Consensus, as
"To Be Determined" (TBD). defined in RFC 2434 [8].
3. The author submits the Internet Draft for review through the IETF
standards process as defined in "Internet Official Protocol
Standards" (STD 1).
4. The new protocol progresses through the IETF standards process;
the specification of the new protocol will be reviewed by the
Dynamic Host Configuration Working Group (if that group still
exists), or as an Internet Draft not submitted by an IETF working
group. If the option is accepted as a Standard, the specification
for the option is published as a separate RFC.
5. At the time of acceptance as a Proposed Internet Standard and
publication as an RFC, IANA assigns a DHCP authentication protocol
number to the new protocol.
This procedure for defining new authentication protocols will ensure The Algorithm name space is specific to individual Protocols. That
that: is, each Protocol has its own Algorithm name space. The guidelines
for assigning Algorithm name space values for a particular protocol
should be specified along with the definition of a new Protocol.
* allocation of new protocol numbers is coordinated from a single For the configuration token Protocol, the Algorithm field MUST be 0.
authority, For the delayed authentication Protocol, the Algorithm value 1 is
* new protocols are reviewed for technical correctness and assigned to the HMAC-MD5 generating function as defined in section 5.
appropriateness, and Additional values from the Algorithm name space for Algorithm 1 will
* documentation for new protocols is complete and published. be assigned through IETF Consensus, as defined in RFC 2434.
DISCUSSION: The initial value of 0 from the RDM name space is assigned to the use
This procedure is patterned after the procedure for acceptance of of a monotonically increasing value as defined in section 2.
new DHCP options. Additional values from the RDM name space will be assigned through
IETF Consensus, as defined in RFC 2434.
7. References 7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
March 1997. 1997.
[2] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC-1321, April 1992.
[3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC-2104, February 1997.
[4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
DRAFT Authentication for DHCP Messages November 2000 [3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
[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
Levels," RFC-2219, March 1997. Levels", RFC 2219, March 1997.
[6] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions," RFC-2132, March 1997. Extensions", RFC 2132, March 1997.
[7] Patrick, M., "DHCP Relay Agent Information Option," [7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
<draft-ietf-dhc-agent-options-12.txt> (work in progress), January 2001.
October 2000.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
8. Acknowledgments 8. Acknowledgments
Jeff Schiller and Christian Huitema developed the original version of Jeff Schiller and Christian Huitema developed the original version of
this authentication protocol in a terminal room BOF at the Dallas this authentication protocol in a terminal room BOF at the Dallas
IETF meeting, December 1995. One of the editors (Droms) transcribed IETF meeting, December 1995. One of the editors (Droms) transcribed
the notes from that discussion, which form the basis for this the notes from that discussion, which form the basis for this
document. The editors appreciate Jeff's and Christian's patience in document. The editors appreciate Jeff's and Christian's patience in
reviewing this document and its earlier drafts. reviewing this document and its earlier drafts.
skipping to change at page 14, line 45 skipping to change at page 14, line 5
Arun Kapur, developed the threat model and reviewed several Arun Kapur, developed the threat model and reviewed several
alternative proposals. alternative proposals.
The replay detection method field is due to Vipul Gupta. The replay detection method field is due to Vipul Gupta.
Other input from Bill Sommerfield is gratefully acknowledged. Other input from Bill Sommerfield is gratefully acknowledged.
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
Narten for reviewing earlier drafts of this document. Narten for reviewing earlier drafts of this document.
9. Security considerations 9. Security Considerations
This document describes authentication and verification mechanisms This document describes authentication and verification mechanisms
for DHCP. for DHCP.
9.1 Protocol vulnerabilities 9.1 Protocol vulnerabilities
The clear text password authentication mechanism (authentication The configuration token authentication mechanism is vulnerable to
protocol 0) is vulnerable to interception and provides only the most interception and provides only the most rudimentary protection
against inadvertently instantiated DHCP servers.
DRAFT Authentication for DHCP Messages November 2000
rudimentary protection against inadvertently instantiated DHCP
servers.
The delayed authentication mechanism described in this document The delayed authentication mechanism described in this document is
(authentication protocol 1) is vulnerable to a denial of service vulnerable to a denial of service attack through flooding with
attack through flooding with DHCPDISCOVER messages, which are not DHCPDISCOVER messages, which are not authenticated by this protocol.
authenticated by this protocol. Such an attack may overwhelm the Such an attack may overwhelm the computer on which the DHCP server is
computer on which the DHCP server is running and may exhaust the running and may exhaust the addresses available for assignment by the
addresses available for assignment by the DHCP server. DHCP server.
Authentication protocol 1 may also be vulnerable to a denial of Delayed authentication may also be vulnerable to a denial of service
service attack through flooding with authenticated messages, which attack through flooding with authenticated messages, which may
may overwhelm the computer on which the DHCP server is running as the overwhelm the computer on which the DHCP server is running as the
authentication keys for the incoming messages are computed. authentication keys for the incoming messages are computed.
9.2 Protocol limitations 9.2 Protocol limitations
Authentication protocol 1 does not support interdomain Delayed authentication does not support interdomain authentication.
authentication.
A real digital signature mechanism such as RSA, while currently A real digital signature mechanism such as RSA, while currently
computationally infeasible, would provide better security. computationally infeasible, would provide better security.
10. Editors' addresses 10. Editors' Addresses
Ralph Droms Ralph Droms
Cisco Systems Cisco Systems
300 Apollo Drive 300 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4733 Phone: (978) 244-4733
EMail: rdroms@cisco.com EMail: rdroms@cisco.com
Bill Arbaugh Bill Arbaugh
Department of Computer Science Department of Computer Science
University of Maryland University of Maryland
A.V. Williams Building A.V. Williams Building
College Park, MD 20742 College Park, MD 20742
Phone: (301) 455-2774 Phone: (301) 405-2774
Email: waa@cs.umd.edu EMail: waa@cs.umd.edu
10. Expiration
This document will expire on May 1, 2001.
DRAFT Authentication for DHCP Messages November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 November 2000
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 [6], for each client is generated from the pair (client identifier [6],
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.
By deriving all keys from a single master key, the DHCP server does By deriving all keys from a single master key, the DHCP server does
not need access to clear text passwords, and can compute and verify not need access to clear text passwords, and can compute and verify
the keyed MACs without requiring help from a centralized the keyed MACs without requiring help from a centralized
authentication server. authentication server.
To avoid compromise of this key management system, the master key, To avoid compromise of this key management system, the master key,
MK, MUST NOT be stored by any clients. The client SHOULD only be 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 given its key, K. If MK is compromised, a new MK SHOULD be chosen
and all clients given new individual keys. and all clients given new individual keys.
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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