draft-ietf-dhc-auth-suboption-00.txt   draft-ietf-dhc-auth-suboption-01.txt 
DHC Working Group M. Stapp DHC Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: December 22, 2002 T. Lemon Expires: May 2, 2003 T. Lemon
Nominum, Inc. Nominum, Inc.
June 23, 2002 November 1, 2002
The Authentication Suboption for the DHCP Relay Agent Option The Authentication Suboption for the DHCP Relay Agent Option
<draft-ietf-dhc-auth-suboption-00.txt> <draft-ietf-dhc-auth-suboption-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2002. This Internet-Draft will expire on May 2, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The DHCP Relay Agent Information Option RFC3046[1] conveys The DHCP Relay Agent Information Option (RFC3046[1]) conveys
information between a DHCP Relay Agent and a DHCP server. This information between a DHCP Relay Agent and a DHCP server. This
specification defines a new authentication suboption for that option specification defines a new authentication suboption for that option
which supports source entity authentication and data integrity for which supports source entity authentication and data integrity for
that option. The authentication suboption contains a payload derived relayed DHCP messages. The authentication suboption contains a
from the option used in DHCP Authentication RFC3118[2]. cryptographic signature in a payload derived from the option used in
DHCP Authentication (RFC3118[2]).
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3
1.2 DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 1.2 DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4 3. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
4. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5 4. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
5. Computing Authentication Information . . . . . . . . . . . . 5 5. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
5.1 The HMAC-MD5 Algorithm . . . . . . . . . . . . . . . . . . . 6 6. Computing Authentication Information . . . . . . . . . . . . 6
6. Procedures for Sending Messages . . . . . . . . . . . . . . 7 6.1 The HMAC-MD5 Algorithm . . . . . . . . . . . . . . . . . . . 6
6.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 7 7. Procedures for Sending Messages . . . . . . . . . . . . . . 8
6.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . . 7 7.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 8
6.3 Signature Computation . . . . . . . . . . . . . . . . . . . 7 7.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . . 8
6.4 Sending the Message . . . . . . . . . . . . . . . . . . . . 8 7.3 Signature Computation . . . . . . . . . . . . . . . . . . . 8
7. Procedures for Processing Incoming Messages . . . . . . . . 8 7.4 Sending the Message . . . . . . . . . . . . . . . . . . . . 8
7.1 Initial Examination . . . . . . . . . . . . . . . . . . . . 8 8. Procedures for Processing Incoming Messages . . . . . . . . 8
7.2 Replay Detection Check . . . . . . . . . . . . . . . . . . . 8 8.1 Initial Examination . . . . . . . . . . . . . . . . . . . . 9
7.3 Signature Check . . . . . . . . . . . . . . . . . . . . . . 9 8.2 Replay Detection Check . . . . . . . . . . . . . . . . . . . 9
8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9 8.3 Signature Check . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Sending Messages to Servers . . . . . . . . . . . . . . . . 9 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 10
8.2 Receiving Messages from Servers . . . . . . . . . . . . . . 9 9.1 Receiving Messages from Other Relay Agents . . . . . . . . . 10
9. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9 9.2 Sending Messages to Servers . . . . . . . . . . . . . . . . 10
9.1 Receiving Messages from Relay Agents . . . . . . . . . . . . 10 9.3 Receiving Messages from Servers . . . . . . . . . . . . . . 10
9.2 Sending Reply Messages to Relay Agents . . . . . . . . . . . 10 10. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 10.1 Receiving Messages from Relay Agents . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 10 10.2 Sending Reply Messages to Relay Agents . . . . . . . . . . . 11
11.1 Protocol Vulnerabilities . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1 Protocol Vulnerabilities . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
1. Terminology 1. Terminology
1.1 Requirements Terminology 1.1 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[3]. document are to be interpreted as described in RFC 2119[3].
1.2 DHCP Terminology 1.2 DHCP Terminology
skipping to change at page 3, line 26 skipping to change at page 3, line 26
Is there anything that should go here, or do we think that Is there anything that should go here, or do we think that
readers will be sufficiently familiar with DHCP? readers will be sufficiently familiar with DHCP?
2. Introduction 2. Introduction
DHCP (RFC2131[4]) provides IP addresses and configuration DHCP (RFC2131[4]) 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,
in which processes within the network infrastructure receive in which processes within the network infrastructure receive
broadcast messages from clients and forward them to servers as broadcast messages from clients and forward them to servers as
unicast messages. In network environments like DOCSIS unicast messages. In network environments like DOCSIS
data-over-cable and DSL, it has proven useful for the relay agent to data-over-cable and xDSL, for example, it has proven useful for the
add information to the DHCP message before forwarding it, using the relay agent to add information to the DHCP message before forwarding
relay-agent information option, RFC3046[1]. The kind of information it, using the relay-agent information option, RFC3046[1]. The kind
that relays add is often used in the server's decision making about of information that relays add is often used in the server's
the addresses and configuration parameters that the client should decision making about the addresses and configuration parameters
receive. The way that the relay-agent data is used in server that the client should receive. The way that the relay-agent data is
decision-making tends to make that data very important, and used in server decision-making tends to make that data very
highlights the importance of the trust relationship between the important, and highlights the importance of the trust relationship
relay agent and the server. between the relay agent and the server.
The existing DHCP Authentication[2] specification only covers The existing DHCP Authentication[2] specification only covers
communication between the DHCP client and server. Because communication between the DHCP client and server. Because
relay-agent information is added after the client has signed its relay-agent information is added after the client has signed its
message, the DHCP Authentication specification explictly excludes message, the DHCP Authentication specification explictly excludes
relay-agent data from that authentication. relay-agent data from that authentication.
The goals of this specification are: The goals of this specification are:
1. to define a method that a relay-agent can use to protect the 1. to define a method that a relay-agent can use to protect the
integrity of the data that the relay adds integrity of the data that the relay adds
2. to provide replay protection for that data 2. to provide replay protection for that data
3. to leverage the mechanisms that DHCP Authentication specifies 3. to leverage the mechanisms that DHCP Authentication specifies
in order to leverage the security review and implementation in order to leverage the security review and implementation
code-base of that specification. code-base of that specification.
In order to meet these goals, we specify a new relay-agent In order to meet these goals, we specify a new relay-agent
suboption, the Authentication suboption. The format of this suboption, the Authentication suboption. The format of this
suboption is very similar to the DHCP Authentication option's suboption is very similar to the DHCP Authentication option's
format, and the specification of the cryptographic methods and format, and the specification of the cryptographic methods and
signature computation for the suboption are inherited from that signature computation for the suboption are also similar to that
option. option's specification.
The Authentication suboption is included by relay agents who wish to The Authentication suboption is included by relay agents that wish
ensure the integrity of the data they include in the Relay Agent to 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 cryptographically strong signatures of the necessary to generate cryptographically strong signatures of the
data in the DHCP messages which they forward to DHCP servers. A DHCP data in the DHCP messages which they forward to DHCP servers. A DHCP
server configured to process the Authentication suboption uses the server configured to process the Authentication suboption uses the
information in the suboption to validate the signature in the information in the suboption to validate the signature in the
suboption, and continues processing the packet only if the signature suboption, and continues processing the relay-agent information
is valid. If the DHCP server sends a response, it includes an option only if the signature is valid. If the DHCP server sends a
Authentication suboption in its response message, signing the data response, it includes an Authentication suboption in its response
in its message. Relay agents check the signatures in DHCP server message, signing the data in its message. Relay agents check the
responses and decide whether to forward the responses based on the signatures in DHCP server responses and decide whether to forward
signatures' validity. the responses based on the signatures' validity.
3. Suboption Format 3. Suboption Format
The format of the Authentication suboption is inherited from the
DHCP Authentication option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Algorithm | MBZ | RDM | | Code | Length | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) | | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. | | Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Authentication Information | | Authentication Information |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the suboption is TBD. The length field includes the The code for the suboption is TBD. The length field includes the
lengths of the algorithm, RDM, and all subsequent suboption fields lengths of the algorithm, RDM, and all subsequent suboption fields
in octets. 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
zero, and MUST be ignored 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 Reply Detection field contains a value used to detect replays, The Replay Detection field contains a value used to detect replayed
interpreted according to the RDM. messages, interpreted according to the RDM.
The Relay Identifier field is used by relays which do not set
giaddr, as described in RFC3046[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 signature. communicate algorithm-specific parameters, as well as the signature.
The signature is usually a digest of the data in the DHCP packet The signature is usually a digest of the data in the DHCP packet
computed using the method specified by the Algorithm field. computed using the method specified by the Algorithm field.
4. Replay Detection 4. Replay Detection
The replay-detection mechanism is based on the notion that a The replay-detection mechanism is based on the notion that a
receiver can determine whether or not a message has a valid replay receiver can determine whether or not a message has a valid replay
skipping to change at page 5, line 31 skipping to change at page 5, line 37
Detection counter value less than the last valid value. DHCP servers Detection counter value less than the last valid value. DHCP servers
MAY identify relays by giaddr value or by other data in the message MAY identify relays by giaddr value or by other data in the message
(e.g. data in other relay-agent suboptions). Relays identify DHCP (e.g. data in other relay-agent suboptions). Relays identify DHCP
servers by source IP address. If the message's replay detection servers by source IP address. If the message's replay detection
value is valid, and the signature is also valid, the receiver value is valid, and the signature is also valid, the receiver
updates the its notion of the last valid replay counter value updates the its notion of the last valid replay counter value
associated with the sender. associated 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 10. Section 11.
Receivers SHOULD perform the replay-detection check before Receivers SHOULD perform the replay-detection check before
validating the signature. The authentication hash calculation is validating the signature. The authentication hash calculation is
likely to be much more expensive than the replay-detection value likely to be much more expensive than the replay-detection value
check. 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, but
the number of members in a DHCP agent-server system is unlikely the number of members in a DHCP agent-server system is unlikely
to be unmanageably large. to be unmanageably large.
5. Computing Authentication Information 5. The Relay Identifier Field
The Relay-Agent Information Option[1] specification permits a relay
to add a relay-agent option to relayed messages without setting the
giaddr field. In this case, the eventual receiver of the message
needs a stable identifier to use in order to associate per-sender
state such as Key ID and replay-detection counters.
A relay which adds a relay-agent information option and sets giaddr
MUST NOT set the Relay ID field. A relay which does not set giaddr
MAY be configured to place a value in the Relay ID field. If the
relay 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 value
based on some other data, such its MAC or IP addresses. If a relay
generates a Relay ID value it SHOULD select a value that it can
regenerate reliably, e.g. across reboots.
Servers which process an Authentication Suboption SHOULD use the
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
identify the signer. 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 ID field is set, the server MAY be configured to use some
other data in the message, or it MAY increment an error counter.
6. Computing Authentication Information
The Authentication Information field contains a computed signature, The Authentication Information field contains a computed signature,
generated by the sender. All algorithms are defined to process the generated by the sender. All algorithms are defined to process the
data in the DHCP messages in the same way. The sender and receiver data in the DHCP messages in the same way. The sender and receiver
compute the signature across a buffer containing all of the bytes in compute the signature across a buffer containing all of the bytes in
the DHCP message, including the fixed DHCP message header, the DHCP the DHCP message, including the fixed DHCP message header, the DHCP
options, and the relay-agent suboption, with the following options, and the relay-agent suboptions, with the following
exceptions. The value of the 'hops' field MUST be set to zero, exceptions. The value of the 'hops' field MUST be set to zero,
because its value may be changed in transmission. The value of the because its value may be changed in transmission. The value of the
'giaddr' field MUST also be set to all-zeroes because it may be 'giaddr' field MUST also be set to all-zeroes 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 sets 'giaddr' (see RFC3046[1], section option but another relay sets 'giaddr' (see RFC3046[1], section
2.1). In addition, because the relay-agent option itself is included 2.1). In addition, because the relay-agent option itself is included
in the computation, the 'signature' part of the 'authentication in the computation, the 'signature' part of the 'authentication
information' field in the Authentication suboption is set to all information' field in the Authentication suboption is set to all
zeroes. The relay-agent option length, the Authentication suboption zeroes. The relay-agent option length, the Authentication suboption
length and other Authentication suboption fields are all included in length and other Authentication suboption fields are all included in
the computation. the computation.
All implementations MUST support Algorithm 1, the HMAC-MD5 All implementations MUST support Algorithm 1, the HMAC-MD5
algorithm. Additional algorithms may be defined in the future, algorithm. Additional algorithms may be defined in the future,
following the process described in Section 10. following the process described in Section 11.
5.1 The HMAC-MD5 Algorithm 6.1 The HMAC-MD5 Algorithm
Algorithm 1 is assigned to the HMAC[5] protocol, using the MD5[6] Algorithm 1 is assigned to the HMAC[5] protocol, using the MD5[6]
hash function. This algorithm requires that a shared secret key be hash function. This algorithm requires that a shared secret key be
configured at the relay agent and the DHCP server. A 32-bit Key configured at the relay agent and the DHCP server. A 32-bit Key
Identifier is associated with each shared key, and this identifier Identifier is associated with each shared key, and this identifier
is carried in the first 4 bytes of the Authentication Information is carried in the first 4 bytes of the Authentication Information
field of the Authentication suboption. The HMAC-MD5 computation field of the Authentication suboption. The HMAC-MD5 computation
generates a 16-byte signature, which is placed in the Authentication generates a 16-byte signature, which is placed in the Authentication
Information field after the Key ID. Information field after the Key ID.
skipping to change at page 6, line 41 skipping to change at page 7, line 23
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 | 34 |0 0 0 0 0 0 0 1| MBZ | RDM | | Code | 34 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) | | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. | | Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) | | Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC-MD5 (128 bits) | | HMAC-MD5 (128 bits) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The suboption length is 34, the RDM and Replay Detection fields are The suboption length is 34. The RDM and Replay Detection fields are
as specified in Section 4, the Key ID is set by the sender to the ID as specified in Section 4. The Relay ID field is set as specified in
of the key used in computing the signature, as an integer value in Section 5. The Key ID is set by the sender to the ID of the key used
network byte-order. The HMAC signature follows the Key ID. in computing the signature, as an integer value in network
byte-order. The HMAC signature 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 need to be locally unique.
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.
DISCUSSION: DISCUSSION:
We specify a four-byte Key ID, following the example of the DHCP We specify a four-byte Key ID, following the example of the DHCP
Authentication RFC. Other authentication protocols, like DNS Authentication RFC. Other authentication protocols, like DNS
TSIG[7], use a key name. A key name is more flexible and TSIG[7], use a key name. A key name is more flexible and
potentially more human-readable than a key id. DHCP servers may potentially more human-readable than a key id. DHCP servers may
well be configured to use key names for DNS updates using TSIG, well be configured to use key names for DNS updates using TSIG,
so it might simplify DHCP server configuration if some of the so it might simplify DHCP server configuration if some of the
key-management for both protocols could be shared. Should we key-management for both protocols could be shared.
specify a variable-length Key Name instead of a fixed-length Key On the other hand, it is crucial to minimize the size expansion
ID? caused by the introduction of the relay-agent information option.
Named keys would require more physical space, and would entail
more complex suboption encoding and parsing implementations.
These considerations have led us to specify a fixed-length Key ID
instead of a variable-length key name.
6. Procedures for Sending Messages 7. Procedures for Sending Messages
6.1 Replay Detection 7.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.
6.2 Packet Preparation 7.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
zeroes. The sender appends the relay-agent information option to the zeroes. The sender appends the relay-agent information option to the
client's packet, including the Authentication suboption. The sender client's packet, including the Authentication suboption. The sender
sets the suboption length, places the Replay Detection value into selects an appropriate Replay Detection value. The sender places its
the Replay Detection field of the suboption, and sets the algorithm identifier into the Relay ID field, if necessary, or sets the field
to the algorithm number that it is using. If the sender is using to all zeroes. The sender sets the suboption length, places the
HMAC-MD5, it sets the Key ID field to the appropriate value. The Replay Detection value into the Replay Detection field of the
sender sets the field which will contain the signature to all suboption, and sets the algorithm to the algorithm number that it is
zeroes. Other algorithms may specify additional preparation steps. using. If the sender is using HMAC-MD5, it sets the Key ID field to
the appropriate value. The sender sets the field which will contain
the signature to all zeroes. Other algorithms may specify additional
preparation steps.
6.3 Signature Computation 7.3 Signature Computation
The sender computes the signature across the entire DHCP message, The sender computes the signature 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 signature field of the Authentication the computation into the signature field of the Authentication
suboption. suboption.
6.4 Sending the Message 7.4 Sending the Message
The sender restores the 'hops' field's value, and sends the message. The sender restores the values of the 'hops' and 'giaddr' fields,
and sends the message.
7. Procedures for Processing Incoming Messages 8. Procedures for Processing Incoming Messages
7.1 Initial Examination 8.1 Initial Examination
The receiver examines the message, the value of the giaddr field, The receiver examines the message, the value of the giaddr field,
and determines whether the packet includes the relay-agent and determines whether the packet includes the relay-agent
information option. The receiver uses its configuration to determine information option. The receiver uses its configuration to determine
whether it should expect an Authentication suboption. The receiver whether it should expect an Authentication suboption. The receiver
MAY be configured to drop incoming messages which do not contain a MAY be configured to drop incoming messages which do not contain a
valid relay agent information option and Authentication suboption. valid relay agent information option and 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 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 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 be configured to drop the indicated in the message, it SHOULD drop the message. Because this
message. Because this situation could indicate a misconfiguration situation could indicate a misconfiguration which could deny service
which could deny service to clients, receivers MAY attempt to notify to clients, receivers MAY attempt to notify their administrators or
their administrators or log an error message. log an error message.
7.2 Replay Detection Check 8.2 Replay Detection Check
The receiver examines the RDM field. Receivers MUST discard The receiver examines the RDM field. Receivers MUST discard
messages containing RDM values which they do not support. Because messages containing RDM values which they do not support. Because
this may indicate a misconfiguration at the sender, an attempt this may indicate a misconfiguration at the sender, an attempt
SHOULD be made to indicate this condition to the administrator, by SHOULD be made to indicate this condition to the administrator, by
incrementing an error counter or writing a log message. If the incrementing an error counter or writing a log message. If the
receiver supports the RDM, it examines the value in the Replay receiver supports the RDM, it examines the value in the Replay
Detection field using the procedures in the RDM and in Section 4. If Detection field using the procedures in the RDM and in Section 4. If
the Replay value is not valid, the receiver MUST drop the message. the Replay value is not valid, the receiver MUST drop the message.
DISCUSSION: Note that the receiver MUST NOT update its notion of the last valid
Note that the receiver must not update its notion of the last Replay Detection value for the sender at this point. Until the
valid Replay Detection value for the sender at this point. Until signature has been checked, the Replay Detection field cannot be
the signature has been checked, the Replay Detection field cannot trusted. If the receiver trusts the Replay Detection value without
be trusted. If the receiver trusts the Replay Detection value checking the signature, a malicious host could send a replayed
without checking the signature, a malicious host could send a message with a Replay Detection value that was very high, tricking
replayed message with a Replay Detection value that was very the receiver into rejecting legitimate values from the sender.
high, tricking the receiver into rejected legitimate values from
the sender.
7.3 Signature Check 8.3 Signature Check
The receiver prepares the packet in order to check the signature. The receiver prepares the packet in order to check the signature.
The receiver sets the 'giaddr' and 'hops' fields to zero, and sets The receiver sets the 'giaddr' and 'hops' fields to zero, and sets
the signature field of the Authentication suboption to all zeroes. the signature field of the Authentication suboption to all zeroes.
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 signatures its computation with the value sent by the sender. If the signatures
do not match, the receiver MUST drop the message. Otherwise, the do not match, the receiver MUST drop the message. Otherwise, the
receiver updates its notion of the last valid Replay Detection value receiver updates its notion of the last valid Replay Detection value
associated with the sender, and processes the message. associated with the sender, and processes the message.
8. Relay Agent Behavior 9. 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 which implements this suboption or more DHCP servers. A relay agent which 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) to use. Relay implementations SHOULD support
configuration which indicates that all relayed messages should configuration which indicates that all relayed messages should
include the authentication suboption. This SHOULD be disabled by include the authentication suboption. This SHOULD be disabled by
default. Relays MAY support configuration that indicates that default. Relays MAY support configuration that indicates that
certain destination servers support the authentication suboption, certain destination servers support the authentication suboption,
while other servers do not. Relays MAY support configuration of a while other servers do not. Relays MAY support configuration of a
single algorithm number and key to be used with all DHCP servers, or single algorithm number and key to be used with all DHCP servers, or
they MAY support configuration of different algorithms and keys for they MAY support configuration of different algorithms and keys for
each server. each server.
8.1 Sending Messages to Servers 9.1 Receiving Messages from Other Relay Agents
There are network configurations in which one relay agent adds the
relay-agent option, and then forwards the DHCP message to another
relay. For example, a layer-2 switch might be directly connected to
a client, and it might forward messages to an aggregating router,
which sets giaddr and then forwards the message to a DHCP server.
When a DHCP relay which implements the Authentication suboption
receives a message, it MAY use the procedures in Section 8 to verify
the source of the message before forwarding it.
9.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 relays) should receive determines which DHCP servers (or other relays) should receive
copies of the message. If the relay is configured to include the copies of the message. If the relay is configured to include the
Authentication suboption, it determines which Algorithm and RDM to Authentication suboption, it determines which Algorithm and RDM to
use, and then it performs the steps in Section 6. use, and then it performs the steps in Section 7.
8.2 Receiving Messages from Servers 9.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 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 MAY be configured to drop response messages that do not relay MAY be configured to drop response messages that do not
contain the Authentication suboption. The relay then follows the contain the Authentication suboption. The relay then follows the
procedures in Section 7. procedures in Section 8.
9. DHCP Server Behavior 10. 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 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
configuration which specifies the algorithm and key to use with each configuration which specifies the algorithm and key to use with each
relay agent individually. relay agent individually.
9.1 Receiving Messages from Relay Agents 10.1 Receiving Messages from Relay Agents
When a DHCP server which implements the Authentication suboption When a DHCP server which implements the Authentication suboption
receives a message, it performs the steps in Section 7. receives a message, it performs the steps in Section 8.
9.2 Sending Reply Messages to Relay Agents 10.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 6. performs the steps in Section 7.
DISCUSSION: DISCUSSION:
This server behavior represents a slight variance from This server behavior represents a slight variance from
RFC3046[1], Section 2.2. The Authentication suboption is not RFC3046[1], Section 2.2. The Authentication suboption is not
echoed back from the server to the relay: the server generates echoed back from the server to the relay: the server generates
its own suboption. its own suboption.
10. IANA Considerations 11. IANA Considerations
Section 3 defines a new suboption for the DHCP relay-agent option, Section 3 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 is requested to allocate a
new suboption code from the relay-agent option suboption number new 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 are to be created and maintained by IANA.
The Algorithm identifier is a one-byte value. Algorithm value 0 is The Algorithm identifier is a one-byte value. Algorithm value 0 is
reserved. Algorithm value 1 is assigned to the HMAC-MD5 signature as reserved. Algorithm value 1 is assigned to the HMAC-MD5 signature as
defined in Section 5.1. Additional algorithm values will be defined in Section 6.1. Additional algorithm values will be
allocated and assigned through IETF consensus, as defined in RFC allocated and assigned through IETF consensus, as defined in RFC
2434[8]. 2434[8].
The RDM identifier is a four-bit value. RDM value 0 is reserved. RDM The RDM identifier is a four-bit value. RDM value 0 is reserved. RDM
value 1 is assigned to the use of a monotonically increasing counter value 1 is assigned to the use of a monotonically increasing counter
value as defined in Section 4. Additional RDM values will be value as defined in Section 4. Additional RDM values will be
allocated and assigned through IETF consensus, as defined in RFC allocated and assigned through IETF consensus, as defined in RFC
2434[8]. 2434[8].
11. Security Considerations 12. Security Considerations
This specification describes a protocol to add source authentication This specification describes a protocol to add source authentication
and message integrity protection to the messages between DHCP relay and message integrity protection to the messages between DHCP relay
agents and DHCP servers. 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 calculations when they send and receive messages. This burden may
add latency to DHCP messages exchanges. Because relay agents are add latency to DHCP messages exchanges. Because relay agents are
involved when clients reboot, periods of very high reboot activity involved when clients reboot, periods of very high reboot activity
will result in the largest number of messages which have to be will result in the largest number of messages which have to be
signed and verified. During a cable MSO head-end reboot event, for signed and verified. During a cable MSO head-end reboot event, for
example, the time required for all clients to be served may increase. example, the time required for all clients to be served may increase.
11.1 Protocol Vulnerabilities 12.1 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 a different order than the order in which they
were generated. The replay-detection mechanism will cause receivers were generated. The replay-detection mechanism will cause receivers
to drop packets which are delivered 'late', leading to client to drop packets which are delivered 'late', leading to client
retries. The retry mechanisms which most clients implement should retries. The retry mechanisms which most clients implement should
not cause this to be an enormous issue, but it will cause senders to not cause this to be an enormous issue, but it will cause senders to
do computational work which will be wasted if their messages are do computational work which will be wasted if their messages are
re-ordered. re-ordered.
12. Acknowledgements 13. 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.
References 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.
 End of changes. 

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