draft-ietf-dhc-auth-suboption-05.txt   rfc4030.txt 
DHC Working Group M. Stapp Network Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Request for Comments: 4030 Cisco Systems, Inc.
Expires: February 7, 2005 T. Lemon Category: Standards Track T. Lemon
Nominum, Inc. Nominum, Inc.
August 9, 2004 March 2005
The Authentication Suboption for the DHCP Relay Agent Option
<draft-ietf-dhc-auth-suboption-05.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The Authentication Suboption for the
www.ietf.org/ietf/1id-abstracts.txt. Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 7, 2005. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
The DHCP Relay Agent Information Option (RFC 3046) conveys The Dynamic Host Configuration Protocol (DHCP) Relay Agent
information between a DHCP Relay Agent and a DHCP server. This Information Option (RFC 3046) conveys information between a DHCP
specification defines an authentication suboption for that option, Relay Agent and a DHCP server. This specification defines an
containing a keyed hash in its payload. The suboption supports data authentication suboption for that option, containing a keyed hash in
integrity and replay protection for relayed DHCP messages. its payload. The suboption supports data integrity and replay
protection for relayed DHCP messages.
Table of Contents Table of Contents
1. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4 4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5 5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5 6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
7. Computing Authentication Information . . . . . . . . . . . . 6 7. Computing Authentication Information . . . . . . . . . . . . 6
7.1 The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . . . 6 7.1. The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . 6
8. Procedures for Sending Messages . . . . . . . . . . . . . . 7 8. Procedures for Sending Messages . . . . . . . . . . . . . . 7
8.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . 7 8.1. Replay Detection . . . . . . . . . . . . . . . . . . . 7
8.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . 8 8.2. Packet Preparation . . . . . . . . . . . . . . . . . . 8
8.3 Checksum Computation . . . . . . . . . . . . . . . . . . . 8 8.3. Checksum Computation . . . . . . . . . . . . . . . . . 8
8.4 Sending the Message . . . . . . . . . . . . . . . . . . . 8 8.4. Sending the Message . . . . . . . . . . . . . . . . . 8
9. Procedures for Processing Incoming Messages . . . . . . . . 8 9. Procedures for Processing Incoming Messages . . . . . . . . 8
9.1 Initial Examination . . . . . . . . . . . . . . . . . . . 8 9.1. Initial Examination . . . . . . . . . . . . . . . . . 8
9.2 Replay Detection Check . . . . . . . . . . . . . . . . . . 9 9.2. Replay Detection Check . . . . . . . . . . . . . . . . 9
9.3 Testing the Checksum . . . . . . . . . . . . . . . . . . . 9 9.3. Testing the Checksum . . . . . . . . . . . . . . . . . 9
10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9 10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9
10.1 Receiving Messages from Other Relay Agents . . . . . . . 10 10.1. Receiving Messages from Other Relay Agents . . . . . . 10
10.2 Sending Messages to Servers . . . . . . . . . . . . . . 10 10.2. Sending Messages to Servers . . . . . . . . . . . . . 10
10.3 Receiving Messages from Servers . . . . . . . . . . . . 10 10.3. Receiving Messages from Servers . . . . . . . . . . . 10
11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10 11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
11.1 Receiving Messages from Relay Agents . . . . . . . . . . 10 11.1. Receiving Messages from Relay Agents . . . . . . . . . 10
11.2 Sending Reply Messages to Relay Agents . . . . . . . . . 10 11.2. Sending Reply Messages to Relay Agents . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . 11
13.1 The Key ID Field . . . . . . . . . . . . . . . . . . . . 12 13.1. The Key ID Field . . . . . . . . . . . . . . . . . . . 12
13.2 Protocol Vulnerabilities . . . . . . . . . . . . . . . . 12 13.2. Protocol Vulnerabilities . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2. DHCP Terminology
This document uses the terms "DHCP server" (or "server") and "DHCP
client" (or "client") as defined in RFC 2131 [6]. The term "DHCP
relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
3. Introduction 1. Introduction
DHCP (RFC 2131 [6]) provides IP addresses and configuration DHCP (RFC 2131 [6]) provides IP addresses and configuration
information for IPv4 clients. It includes a relay-agent capability information for IPv4 clients. It includes a relay-agent capability
(RFC 951 [7], RFC 1542 [8]), in which processes within the network (RFC 951 [7], RFC 1542 [8]) in which processes within the network
infrastructure receive broadcast messages from clients and forward infrastructure receive broadcast messages from clients and forward
them to servers as unicast messages. In network environments like them to servers as unicast messages. In network environments such as
DOCSIS data-over-cable and xDSL, for example, it has proven useful DOCSIS data-over-cable and xDSL, for example, it has proven useful
for the relay agent to add information to the DHCP message before for the relay agent to add information to the DHCP message before
forwarding it, using the relay-agent information option (RFC 3046 forwarding it, by using the relay-agent information option (RFC 3046
[1]). The kind of information that relays add is often used in the [1]). The kind of information that relays add is often used in the
server's decision making about the addresses and configuration server's decision-making about the addresses and configuration
parameters that the client should receive. The way that the parameters that the client should receive. The way that the
relay-agent data is used in server decision-making tends to make that relay-agent data is used in server decision-making tends to make that
data very important, and highlights the importance of the trust data very important, and it highlights the importance of the trust
relationship between the relay agent and the server. relationship between the relay agent and the server.
The existing DHCP Authentication specification (RFC 3118) [9] only The existing DHCP Authentication specification (RFC 3118) [9] only
covers communication between the DHCP client and server. Because covers communication between the DHCP client and server. Because
relay-agent information is added after the client has sent its relay-agent information is added after the client has sent its
message, the DHCP Authentication specification explictly excludes message, the DHCP Authentication specification explicitly excludes
relay-agent data from that authentication. relay-agent data from that authentication.
The goal of this specification is to define methods that a relay The goal of this specification is to define methods that a relay
agent can use to: agent can use to
1. protect the integrity of relayed DHCP messages
2. provide replay protection for those messages 1. protect the integrity of relayed DHCP messages,
3. leverage existing mechanisms such as DHCP Authentication 2. provide replay protection for those messages, and
3. leverage existing mechanisms, such as DHCP Authentication.
In order to meet these goals, we specify a new relay-agent suboption, In order to meet these goals, we specify a new relay-agent suboption,
the Authentication suboption. The format of this suboption is very the Authentication suboption. The format of this suboption is very
similar to the format of the DHCP Authentication option, and the similar to the format of the DHCP Authentication option, and the
specification of the cryptographic methods and hash computation for specification of its cryptographic methods and hash computation is
the suboption are also similar to that specification. also similar.
The Authentication suboption is included by relay agents that wish to The Authentication suboption is included by relay agents that seek to
ensure the integrity of the data they include in the Relay Agent ensure the integrity of the data they include in the Relay Agent
option. These relay agents are configured with the parameters option. These relay agents are configured with the parameters
necessary to generate cryptographic checksums of the data in the DHCP necessary for generating cryptographic checksums of the data in the
messages which they forward to DHCP servers. A DHCP server configured DHCP messages that they forward to DHCP servers. A DHCP server
to process the Authentication suboption uses the information in the configured to process the Authentication suboption uses the
suboption to verify the checksum in the suboption, and continues information in the suboption to verify the checksum in the suboption
processing the relay agent information option only if the checksum is and continues processing the relay agent information option only if
valid. If the DHCP server sends a response, it includes an the checksum is valid. If the DHCP server sends a response, it
Authentication suboption in its response message. Relay agents test includes an Authentication suboption in its response message. Relay
the checksums in DHCP server responses to decide whether to forward agents test the checksums in DHCP server responses to decide whether
the responses. to forward the responses.
2. Requirements Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].
3. DHCP Terminology
This document uses the terms "DHCP server" (or "server") and "DHCP
client" (or "client") as defined in RFC 2131 [6]. The term "DHCP
relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
4. Suboption Format 4. Suboption Format
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 | Algorithm | MBZ | RDM | | Code | Length | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) | | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 36 skipping to change at page 4, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier | | Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Authentication Information | | Authentication Information |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the suboption is TBD. The length field includes the The code for the suboption is 8. The length field includes the
lengths of the algorithm, RDM, and all subsequent suboption fields in lengths of the algorithm, the RDM, and all subsequent suboption
octets. fields in octets.
The Algorithm field defines the algorithm used to generate the The Algorithm field defines the algorithm used to generate the
authentication information. authentication information.
Four bits are reserved for future use. These bits SHOULD be set to Four bits are reserved for future use. These bits SHOULD be set to
zero, and MUST be not be used when the suboption is processed. zero and MUST NOT be used when the suboption is processed.
The Replay Detection Method (RDM) field defines the method used to The Replay Detection Method (RDM) field defines the method used to
generate the Replay Detection Data. generate the Replay Detection Data.
The Replay Detection field contains a value used to detect replayed The Replay Detection field contains a value used to detect replayed
messages, interpreted according to the RDM. messages, which are interpreted according to the RDM.
The Relay Identifier field is used by relay agents that do not set The Relay Identifier field is used by relay agents that do not set
giaddr, as described in RFC 3046 [1], Section 2.1. giaddr, as described in RFC 3046 [1], section 2.1.
The Authentication Information field contains the data required to The Authentication Information field contains the data required to
communicate algorithm-specific parameters, as well as the checksum. communicate algorithm-specific parameters, as well as the checksum.
The checksum is usually a digest of the data in the DHCP packet The checksum is usually a digest of the data in the DHCP packet
computed using the method specified by the Algorithm field. computed by using the method specified by the Algorithm field.
5. Replay Detection 5. Replay Detection
The replay-detection mechanism is based on the notion that a receiver The replay-detection mechanism is designed on the notion that a
can determine whether or not a message has a valid replay token receiver can determine whether a message has a valid replay token
value. The default RDM, with value 1, specifies that the Replay value. The default RDM, with value 1, specifies that the Replay
Detection field contains an increasing counter value. The receiver Detection field contains an increasing counter value. The receiver
associates a replay counter with each sender, and rejects any message associates a replay counter with each sender and rejects any message
containing an authentication suboption with a Replay Detection containing an authentication suboption with a Replay Detection
counter value less than or equal to the last valid value. DHCP counter value less than or equal to the last valid value. DHCP
servers MAY identify relay agents by giaddr value or by other data in servers MAY identify relay agents by giaddr value or by other data in
the message (e.g. data in other relay agent suboptions). Relay agents the message (e.g., data in other relay agent suboptions). Relay
identify DHCP servers by source IP address. If the message's replay agents identify DHCP servers by source IP address. If the message's
detection value is valid, and the checksum is also valid, the replay detection value, and the checksum are valid, the receiver
receiver updates its notion of the last valid replay counter value updates its notion of the last valid replay counter value associated
associated with the sender. with the sender.
All implementations MUST support the default RDM. Additional methods All implementations MUST support the default RDM. Additional methods
may be defined in the future, following the process described in may be defined in the future, following the process described in
Section 12. section 12.
Receivers SHOULD perform the replay-detection check before testing Receivers SHOULD perform the replay-detection check before testing
the checksum. The keyed hash calculation is likely to be much more the checksum. The keyed hash calculation is likely to be much more
expensive than the replay-detection value check. expensive than the replay-detection value check.
DISCUSSION: DISCUSSION:
This places a burden on the receiver to maintain some run-time This places a burden on the receiver to maintain some run-time
state (the most-recent valid counter value) for each sender, but state (the most-recent valid counter value) for each sender,
the number of members in a DHCP agent-server system is unlikely to but the number of members in a DHCP agent-server system is
be unmanageably large. unlikely to be unmanageably large.
6. The Relay Identifier Field 6. The Relay Identifier Field
The Relay Agent Information Option [1] specification permits a relay The Relay Agent Information Option [1] specification permits a relay
agent to add a relay agent option to relayed messages without setting agent to add a relay agent option to relayed messages without setting
the giaddr field. In this case, the eventual receiver of the message the giaddr field. In this case, the eventual receiver of the message
needs a stable identifier to use in order to associate per-sender needs a stable identifier to use in order to associate per-sender
state such as Key ID and replay-detection counters. state such as Key ID and replay-detection counters.
A relay agent that adds a relay agent information option and sets A relay agent that adds a relay agent information option and sets
giaddr MUST NOT set the Relay ID field. A relay agent that does not giaddr MUST NOT set the Relay ID field. A relay agent that does not
set giaddr MAY be configured to place a value in the Relay ID field. set giaddr MAY be configured to place a value in the Relay ID field.
If the relay agent is configured to use the Relay ID field, it MAY be If the relay agent is configured to use the Relay ID field, it MAY be
configured with a value to use, or it MAY be configured to generate a configured with a value to use, or it MAY be configured to generate a
value based on some other data, such its MAC or IP addresses. If a value based on some other data, such as its MAC or IP addresses. If
relay generates a Relay ID value it SHOULD select a value that it can a relay generates a Relay ID value, it SHOULD select a value that it
regenerate reliably, e.g. across reboots. can regenerate reliably; e.g., across reboots.
Servers that process an Authentication Suboption SHOULD use the Servers that process an Authentication Suboption SHOULD use the
giaddr value to identify the sender if the giaddr field is set. giaddr value to identify the sender if the giaddr field is set.
Servers MAY be configured to use some other data in the message to Servers MAY be configured to use some other data in the message to
identify the sender. If giaddr is not set, the server SHOULD use the identify the sender. If giaddr is not set, the server SHOULD use the
Relay ID field if it is non-zero. If neither the giaddr nor the Relay Relay ID field if it is nonzero. If neither the giaddr nor the Relay
ID field is set, the server MAY be configured to use some other data ID field is set, the server MAY be configured to use some other data
in the message, or it MAY increment an error counter. in the message, or it MAY increment an error counter.
7. Computing Authentication Information 7. Computing Authentication Information
The Authentication Information field contains a keyed hash, generated The Authentication Information field contains a keyed hash generated
by the sender. All algorithms are defined to process the data in the by the sender. All algorithms are defined to process the data in the
DHCP messages in the same way. The sender and receiver compute a hash DHCP messages in the same way. The sender and receiver compute a
across a buffer containing all of the bytes in the DHCP message, hash across a buffer containing all of the bytes in the DHCP message,
including the fixed DHCP message header, the DHCP options, and the including the fixed DHCP message header, the DHCP options, and the
relay agent suboptions, with the following exceptions. The value of relay agent suboptions, with the following exceptions. The value of
the 'hops' field MUST be set to zero for the computation, because its the 'hops' field MUST be set to zero for the computation because its
value may be changed in transmission. The value of the 'giaddr' field value may be changed in transmission. The value of the 'giaddr'
MUST also be set to zero for the computation because it may be field MUST also be set to zero for the computation because it may be
modified in networks where one relay agent adds the relay agent modified in networks where one relay agent adds the relay agent
option but another relay agent sets 'giaddr' (see RFC 3046, section option but another relay agent sets 'giaddr' (see RFC 3046, section
2.1). In addition, because the relay agent option itself is included 2.1). In addition, because the relay agent option is itself included
in the computation, the 'authentication information' field in the in the computation, the 'authentication information' field in the
Authentication suboption is set to all zeroes. The relay agent option Authentication suboption is set to all zeros. The relay agent option
length, the Authentication suboption length and other Authentication length, the Authentication suboption length and other Authentication
suboption fields are all included in the computation. suboption fields are all included in the computation.
All implementations MUST support Algorithm 1, the HMAC-SHA1 All implementations MUST support Algorithm 1, the HMAC-SHA1
algorithm. Additional algorithms may be defined in the future, algorithm. Additional algorithms may be defined in the future,
following the process described in Section 12. following the process described in section 12.
7.1 The HMAC-SHA1 Algorithm 7.1. The HMAC-SHA1 Algorithm
Algorithm 1 is assigned to the HMAC [3] protocol, using the SHA-1 [4] Algorithm 1 is assigned to the HMAC [3] protocol by using the SHA-1
hash function. This algorithm requires that a shared secret key be [4] hash function. This algorithm requires that a shared secret key
configured at the relay agent and the DHCP server. A 32-bit Key be configured at the relay agent and the DHCP server. A 32-bit Key
Identifier is associated with each shared key, and this identifier is Identifier is associated with each shared key, and this identifier is
carried in the first 4 bytes of the Authentication Information field carried in the first 4 bytes of the Authentication Information field
of the Authentication suboption. The HMAC-SHA1 computation generates of the Authentication suboption. The HMAC-SHA1 computation generates
a 20-byte hash value, which is placed in the Authentication a 20-byte hash value, which is placed in the Authentication
Information field after the Key ID. Information field after the Key ID.
The format of the Authentication suboption when Algorithm 1 is used When Algorithm 1 is used, the format of the Authentication suboption
is: is as follows:
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 | 38 |0 0 0 0 0 0 0 1| MBZ | RDM | | Code | 38 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) | | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. | | Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 30 skipping to change at page 7, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) | | Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC-SHA1 (160 bits) | | HMAC-SHA1 (160 bits) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The suboption length is 38. The RDM and Replay Detection fields are The suboption length is 38. The RDM and Replay Detection fields are
as specified in Section 5. The Relay ID field is set as specified in as specified in section 5. The Relay ID field is set as specified in
Section 6. The Key ID is set by the sender to the ID of the key used section 6. The Key ID is set by the sender to the ID of the key used
in computing the checksum, as an integer value in network byte-order. in computing the checksum, as an integer value in network byte order.
The HMAC result follows the Key ID. The HMAC result follows the Key ID.
The Key ID exists only to allow the sender and receiver to specify a The Key ID exists only to allow the sender and receiver to specify a
shared secret in cases where more than one secret is in use among a shared secret in cases where more than one secret is in use among a
network's relays and DHCP servers. The Key ID values are entirely a network's relays and DHCP servers. The Key ID values are entirely a
matter of local configuration; they only need to be locally unique. matter of local configuration; they only have to be unique locally.
This specification does not define any semantics or impose any This specification does not define any semantics or impose any
requirements on this algorithm's Key ID values. requirements on this algorithm's Key ID values.
8. Procedures for Sending Messages 8. Procedures for Sending Messages
8.1 Replay Detection 8.1. Replay Detection
The sender obtains a replay-detection counter value to use, based on The sender obtains a replay-detection counter value to use based on
the RDM it is using. If the sender is using RDM 1, the default RDM, the RDM it is using. If the sender is using RDM 1, the default RDM,
the value MUST be greater than any previously-sent value. the value MUST be greater than any previously sent value.
8.2 Packet Preparation 8.2. Packet Preparation
The sender sets the 'giaddr' field and the 'hops' field to all The sender sets the 'giaddr' field and the 'hops' field to all zeros.
zeroes. The sender appends the relay agent information option to the The sender appends the relay agent information option to the client's
client's packet, including the Authentication suboption. The sender packet, including the Authentication suboption. The sender selects
selects an appropriate Replay Detection value. The sender places its an appropriate Replay Detection value. The sender places its
identifier into the Relay ID field, if necessary, or sets the field identifier into the Relay ID field, if necessary, or sets the field
to all zeroes. The sender sets the suboption length, places the to all zeros. The sender sets the suboption length, places the
Replay Detection value into the Replay Detection field of the Replay Detection value into the Replay Detection field of the
suboption, and sets the algorithm to the algorithm number that it is suboption, and sets the algorithm to the algorithm number that it is
using. If the sender is using HMAC-SHA1, it sets the Key ID field to using. If the sender is using HMAC-SHA1, it sets the Key ID field to
the appropriate value. The sender sets the field which will contain the appropriate value. The sender sets the field that will contain
the checksum to all zeroes. Other algorithms may specify additional the checksum to all zeros. Other algorithms may specify additional
preparation steps. preparation steps.
8.3 Checksum Computation 8.3. Checksum Computation
The sender computes the checksum across the entire DHCP message, The sender computes the checksum across the entire DHCP message,
using the algorithm it has selected. The sender places the result of using the algorithm it has selected. The sender places the result of
the computation into the Authentication Information field of the the computation into the Authentication Information field of the
Authentication suboption. Authentication suboption.
8.4 Sending the Message 8.4. Sending the Message
The sender restores the values of the 'hops' and 'giaddr' fields, and The sender restores the values of the 'hops' and 'giaddr' fields and
sends the message. sends the message.
9. Procedures for Processing Incoming Messages 9. Procedures for Processing Incoming Messages
9.1 Initial Examination 9.1. Initial Examination
The receiver examines the message, the value of the giaddr field, and The receiver examines the message for the value of the giaddr field
determines whether the packet includes the relay agent information and determines whether the packet includes the relay agent
option. The receiver uses its configuration to determine whether it information option. The receiver uses its configuration to determine
should expect an Authentication suboption. The receiver MUST support whether it should expect an Authentication suboption. The receiver
configuration that allows it to drop incoming messages that do not MUST support a configuration that allows it to drop incoming messages
contain a valid relay agent information option and Authentication that do not contain a valid relay agent information option and
suboption. Authentication suboption.
If the receiver determines that the Authentication suboption is If the receiver determines that the Authentication suboption is
present and that it should process the suboption, it uses the data in present and that it should process the suboption, it uses the data in
the message to determine which algorithm, key, and RDM to use in the message to determine which algorithm, key, and RDM to use in
validating the message. If the receiver cannot determine which validating the message. If the receiver cannot determine which
algorithm, key, and RDM to use, or if it does not support the value algorithm, key, and RDM to use, or if it does not support the value
indicated in the message, it SHOULD drop the message. Because this indicated in the message, it SHOULD drop the message. Because this
situation could indicate a misconfiguration which could deny service situation could indicate a misconfiguration that could deny service
to clients, receivers MAY attempt to notify their administrators or to clients, receivers MAY attempt to notify their administrators or
log an error message. to log an error message.
9.2 Replay Detection Check 9.2. Replay Detection Check
The receiver examines the RDM field. Receivers MUST discard messages The receiver examines the RDM field. Receivers MUST discard messages
containing RDM values that they do not support. Because this may containing RDM values that they do not support. Because this may
indicate a misconfiguration at the sender, an attempt SHOULD be made indicate a misconfiguration at the sender, an attempt SHOULD be made
to indicate this condition to the administrator, by incrementing an to indicate this condition to the administrator by incrementing an
error counter or writing a log message. If the receiver supports the error counter or writing a log message. If the receiver supports the
RDM, it examines the value in the Replay Detection field using the RDM, it examines the value in the Replay Detection field by using the
procedures in the RDM and in Section 5. If the Replay value is not procedures in the RDM and in section 5. If the Replay value is not
valid, the receiver MUST drop the message. valid, the receiver MUST drop the message.
Note that the receiver MUST NOT update its notion of the last valid Note that at this point the receiver MUST NOT update its notion of
Replay Detection value for the sender at this point. Until the the last valid Replay Detection value for the sender. Until the
checksum has been tested, the Replay Detection field cannot be checksum has been tested, the Replay Detection field cannot be
trusted. If the receiver trusts the Replay Detection value without trusted. If the receiver trusts the Replay Detection value without
testing the checksum, a malicious host could send a replayed message testing the checksum, a malicious host could send a replayed message
with a Replay Detection value that was very high, tricking the with a Replay Detection value that was very high, tricking the
receiver into rejecting legitimate values from the sender. receiver into rejecting legitimate values from the sender.
9.3 Testing the Checksum 9.3. Testing the Checksum
The receiver prepares the packet in order to test the checksum by The receiver prepares the packet in order to test the checksum by
setting the 'giaddr' and 'hops' fields to zero, and setting the setting the 'giaddr' and 'hops' fields to zero, and by setting the
Authentication Information field of the suboption to all zeroes. Authentication Information field of the suboption to all zeros.
Using the algorithm and key associated with the sender, the receiver Using the algorithm and key associated with the sender, the receiver
computes a hash of the message. The receiver compares the result of computes a hash of the message. The receiver compares the result of
its computation with the value sent by the sender. If the checksums its computation with the value sent. If the checksums do not match,
do not match, the receiver MUST drop the message. Otherwise, the the receiver MUST drop the message. Otherwise, the receiver updates
receiver updates its notion of the last valid Replay Detection value its notion of the last valid Replay Detection value associated with
associated with the sender, and processes the message. the sender and processes the message.
10. Relay Agent Behavior 10. Relay Agent Behavior
DHCP Relay agents are typically configured with the addresses of one DHCP Relay agents are typically configured with the addresses of one
or more DHCP servers. A relay agent that implements this suboption or more DHCP servers. A relay agent that implements this suboption
requires an algorithm number for each server, as well as appropriate requires an algorithm number for each server, as well as appropriate
credentials (i.e. keys) to use. Relay implementations SHOULD support credentials (i.e., keys). Relay implementations SHOULD support a
configuration which indicates that all relayed messages should configuration that indicates that all relayed messages should include
include the authentication suboption. Use of the authentication the authentication suboption. Use of the authentication suboption
suboption SHOULD be disabled by default. Relay agents MAY support SHOULD be disabled by default. Relay agents MAY support
configuration that indicates that certain destination servers support configuration that indicates that certain destination servers support
the authentication suboption, while other servers do not. Relay the authentication suboption and that other servers do not. Relay
agents MAY support configuration of a single algorithm number and key agents MAY support configuration of a single algorithm number and key
to be used with all DHCP servers, or they MAY support configuration to be used with all DHCP servers, or they MAY support configuration
of different algorithms and keys for each server. of different algorithms and keys for each server.
10.1 Receiving Messages from Other Relay Agents 10.1. Receiving Messages from Other Relay Agents
There are network configurations in which one relay agent adds the There are network configurations in which one relay agent adds the
relay agent option, and then forwards the DHCP message to another relay agent option and then forwards the DHCP message to another
relay agent. For example, a layer-2 switch might be directly relay agent. For example, a layer-2 switch might be directly
connected to a client, and it might forward messages to an connected to a client, and it might forward messages to an
aggregating router, which sets giaddr and then forwards the message aggregating router, which sets giaddr and then forwards the message
to a DHCP server. When a DHCP relay which implements the to a DHCP server. When a DHCP relay that implements the
Authentication suboption receives a message, it MAY use the Authentication suboption receives a message, it MAY use the
procedures in Section 9 to verify the source of the message before procedures in section 9 to verify the source of the message before
forwarding it. forwarding it.
10.2 Sending Messages to Servers 10.2. Sending Messages to Servers
When the relay agent receives a broadcast packet from a client, it When the relay agent receives a broadcast packet from a client, it
determines which DHCP servers (or other relay agents) should receive determines which DHCP servers (or other relay agents) should receive
copies of the message. If the relay agent is configured to include copies of the message. If the relay agent is configured to include
the Authentication suboption, it determines which Algorithm and RDM the Authentication suboption, it determines which Algorithm and RDM
to use, and then it performs the steps in Section 8. to use, and then it performs the steps in section 8.
10.3 Receiving Messages from Servers 10.3. Receiving Messages from Servers
When the relay agent receives a message, it determines from its When the relay agent receives a message, it determines from its
configuration whether it expects the message to contain a relay agent configuration whether it expects the message to contain a relay agent
information option and an Authentication suboption. The relay agent information option and an Authentication suboption. The relay agent
MAY be configured to drop response messages that do not contain the MAY be configured to drop response messages that do not contain the
Authentication suboption. The relay agent then follows the procedures Authentication suboption. The relay agent then follows the
in Section 9. procedures in section 9.
11. DHCP Server Behavior 11. DHCP Server Behavior
DHCP servers may interact with multiple relay agents. Server DHCP servers may interact with multiple relay agents. Server
implementations MAY support configuration that associates the same implementations MAY support a configuration that associates the same
algorithm and key with all relay agents. Servers MAY support algorithm and key with all relay agents. Servers MAY support a
configuration which specifies the algorithm and key to use with each configuration that specifies the algorithm and key to use with each
relay agent individually. relay agent individually.
11.1 Receiving Messages from Relay Agents 11.1. Receiving Messages from Relay Agents
When a DHCP server which implements the Authentication suboption When a DHCP server that implements the Authentication suboption
receives a message, it performs the steps in Section 9. receives a message, it performs the steps in section 9.
11.2 Sending Reply Messages to Relay Agents 11.2. Sending Reply Messages to Relay Agents
When the server has prepared a reply message, it uses the incoming When the server has prepared a reply message, it uses the incoming
request message and its configuration to determine whether it should request message and its configuration to determine whether it should
include a relay agent information option and an Authentication include a relay agent information option and an Authentication
suboption. If the server is configured to include the Authentication suboption. If the server is configured to include the Authentication
suboption, it determines which Algorithm and RDM to use, and then suboption, it determines which Algorithm and RDM to use and then
performs the steps in Section 8. performs the steps in section 8.
DISCUSSION: DISCUSSION:
This server behavior represents a slight variance from RFC 3046 This server behavior represents a slight variance from RFC 3046
[1], Section 2.2. The Authentication suboption is not echoed back [1], section 2.2. The Authentication suboption is not echoed
from the server to the relay: the server generates its own back from the server to the relay; the server generates its own
suboption. suboption.
12. IANA Considerations 12. IANA Considerations
Section 4 defines a new suboption for the DHCP relay agent option, Section 4 defines a new suboption for the DHCP relay agent option
called the Authentication Suboption. IANA is requested to allocate a called the Authentication Suboption. IANA has allocated a new
new suboption code from the relay agent option suboption number suboption code from the relay agent option suboption number space.
space.
This specification introduces two new number-spaces for the This specification introduces two new number spaces for the
Authentication suboption's 'Algorithm' and 'Replay Detection Method' Authentication suboption's 'Algorithm' and 'Replay Detection Method'
fields. These number spaces are to be created and maintained by IANA. fields. These number spaces have been created and will be maintained
by IANA.
The Algorithm identifier is a one-byte value. Algorithm value 0 is The Algorithm identifier is a one-byte value. The Algorithm value 0
reserved. Algorithm value 1 is assigned to the HMAC-SHA1 keyed hash is reserved. The Algorithm value 1 is assigned to the HMAC-SHA1
as defined in Section 7.1. Additional algorithm values will be keyed hash, as defined in section 7.1. Additional algorithm values
allocated and assigned through IETF consensus, as defined in RFC 2434 will be allocated and assigned through IETF consensus, as defined in
[5]. RFC 2434 [5].
The RDM identifier is a four-bit value. RDM value 0 is reserved. RDM The RDM identifier is a four-bit value. The RDM value 0 is reserved.
value 1 is assigned to the use of a monotonically increasing counter The RDM value 1 is assigned to the use of a monotonically increasing
value as defined in Section 5. Additional RDM values will be counter value, as defined in section 5. Additional RDM values will
allocated and assigned through IETF consensus, as defined in RFC 2434 be allocated and assigned through IETF consensus, as defined in RFC
[5]. 2434 [5].
13. Security Considerations 13. Security Considerations
This specification describes a protocol to add source authentication This specification describes a protocol that adds source
and message integrity protection to the messages between DHCP relay authentication and message integrity protection to the messages
agents and DHCP servers. between DHCP relay agents and DHCP servers.
The use of this protocol imposes a new computational burden on relay The use of this protocol imposes a new computational burden on relay
agents and servers, because they must perform cryptographic hash agents and servers, because they must perform cryptographic hash
calculations when they send and receive messages. This burden may add calculations when they send and receive messages. This burden may
latency to DHCP message exchanges. Because relay agents are involved add latency to DHCP message exchanges. Because relay agents are
when clients reboot, periods of very high reboot activity will result involved when clients reboot, periods of very high reboot activity
in the largest number of messages which have to be processed. During will result in the largest number of messages that have to be
a cable MSO head-end reboot event, for example, the time required for processed. During a cable MSO head-end reboot event, for example,
all clients to be served may increase. the time required for all clients to be served may increase.
13.1 The Key ID Field 13.1. The Key ID Field
The Authentication suboption contains a four-byte Key ID, following The Authentication suboption contains a four-byte Key ID, following
the example of the DHCP Authentication RFC. Other authentication the example of the DHCP Authentication RFC. Other authentication
protocols, like DNS TSIG [10], use a key name. A key name is more protocols, such as DNS TSIG [10], use a key name. A key name is more
flexible and potentially more human-readable than a key id. DHCP flexible and potentially more human readable than a key id. DHCP
servers may well be configured to use key names for DNS updates using servers may well be configured to use key names for DNS updates using
TSIG, so it might simplify DHCP server configuration if some of the TSIG, so it might simplify DHCP server configuration if some of the
key-management for both protocols could be shared. key management for both protocols could be shared.
On the other hand, it is crucial to minimize the size expansion On the other hand, it is crucial to minimize the size expansion
caused by the introduction of the relay agent information option. caused by the introduction of the relay agent information option.
Named keys would require more physical space, and would entail more Named keys would require more physical space and would entail more
complex suboption encoding and parsing implementations. These complex suboption encoding and parsing implementations. These
considerations have led us to specify a fixed-length Key ID instead considerations have led us to specify a fixed-length Key ID instead
of a variable-length key name. of a variable-length key name.
13.2 Protocol Vulnerabilities 13.2. Protocol Vulnerabilities
Because DHCP is a UDP protocol, messages between relays and servers Because DHCP is a UDP protocol, messages between relays and servers
may be delivered in a different order than the order in which they may be delivered in an order different from that in which they were
were generated. The replay-detection mechanism will cause receivers generated. The replay-detection mechanism will cause receivers to
to drop packets which are delivered 'late', leading to client drop packets that are delivered 'late', leading to client retries.
retries. The retry mechanisms which most clients implement should not The retry mechanisms that most clients implement should not cause
cause this to be an enormous issue, but it will cause senders to do this to be an enormous issue, but it will cause senders to do
computational work which will be wasted if their messages are computational work which will be wasted if their messages are
re-ordered. re-ordered.
The DHC WG has developed two documents describing authentication of The DHC WG has developed two documents describing authentication of
DHCP relay agent options to accommodate the requirements of different DHCP relay agent options to accommodate the requirements of different
deployment scenarios: this document and Authentication of Relay Agent deployment scenarios: this document and "Authentication of Relay
Options Using IPsec [11]. As we note in Section 11, the Agent Options Using IPsec" [11]. As we note in section 11, the
Authentication suboption can be used without pairwise keys between Authentication suboption can be used without pairwise keys between
each relay and each DHCP server. In deployments where IPsec is each relay and each DHCP server. In deployments where IPsec is
readily available and pairwise keys can be managed efficiently, the readily available and pairwise keys can be managed efficiently, the
use of IPsec as described in that document may be appropriate. If use of IPsec as described in that document may be appropriate. If
IPsec is not available or there are multiple relay agents for which IPsec is not available or there are multiple relay agents for which
multiple keys must be managed, the protocol described in this multiple keys must be managed, the protocol described in this
document may be appropriate. As is the case whenever two document may be appropriate. As is the case whenever two
alternatives are available, local network administration can choose alternatives are available, local network administration can choose
whichever is more appropriate. Because the relay agents and the DHCP whichever is more appropriate. Because the relay agents and the DHCP
server are all in the same administrative domain, the appropriate server are all in the same administrative domain, the appropriate
mechanism can be configured on all interoperating DHCP server mechanism can be configured on all interoperating DHCP server
elements. elements.
14. Acknowledgements 14. Acknowledgements
The need for this specification was made clear by comments made by The need for this specification was made clear by comments made by
Thomas Narten and John Schnizlein, and the use of the DHCP Thomas Narten and John Schnizlein, and the use of the DHCP
Authentication option format was suggested by Josh Littlefield, at Authentication option format was suggested by Josh Littlefield, at
IETF 53. IETF 53.
Normative References 15. References
15.1. Normative References
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001. January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [4] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Informative References 15.2. Informative References
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[7] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [7] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap [8] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993. Protocol", RFC 1542, October 1993.
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [10] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000. 2845, May 2000.
[11] Droms, R., "Authentication of Relay Agent Options Using IPsec [11] Droms, R., "Authentication of Relay Agent Options Using IPsec",
(draft-ietf-dhc-relay-agent-ipsec-*.txt)", February 2004. Work in Progress, February 2004.
Authors' Addresses Authors' Addresses
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: 978.936.0000 Phone: 978.936.0000
EMail: mjs@cisco.com EMail: mjs@cisco.com
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: Ted.Lemon@nominum.com EMail: Ted.Lemon@nominum.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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