draft-ietf-dhc-relay-agent-auth-00.txt   draft-ietf-dhc-relay-agent-auth-01.txt 
Network Working Group M. Stapp Network Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: October 10, 2003 T. Lemon Expires: December 6, 2003 T. Lemon
Nominum, Inc. Nominum, Inc.
R. Droms R. Droms
Cisco Systems, Inc. Cisco Systems, Inc.
April 11, 2003 June 7, 2003
The Authentication Suboption for the DHCP Relay Agent Option The Authentication Suboption for the DHCP Relay Agent Option
<draft-ietf-dhc-relay-agent-auth-00.txt> <draft-ietf-dhc-relay-agent-auth-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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 October 10, 2003. This Internet-Draft will expire on December 6, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The DHCP Relay Agent Information Option (RFC 3046) conveys The DHCP Relay Agent Information Option (RFC 3046) 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 two mechanisms for securing the messages specification defines two mechanisms for securing the messages
exchanged between a relay agent and a server. The first mechanism exchanged between a relay agent and a server. The first mechanism
defines a new authentication suboption for the Relay Agent defines a new authentication suboption for the Relay Agent
Information Option that supports source entity authentication and Information Option that supports source entity authentication and
data integrity for relayed DHCP messages. The authentication data integrity for relayed DHCP messages. The authentication
suboption contains a cryptographic signature in a payload derived suboption contains a cryptographic signature in a payload derived
from the option used in DHCP Authentication (RFC 3118). The second from the option used in DHCP Authentication (RFC 3118). The second
mechanism uses IPsec (RFC 2041) to protect messages exchanged between mechanism uses IPsec (RFC 2401) to protect messages exchanged between
relay agents and servers. relay agents and servers.
Table of Contents Table of Contents
1. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Option Authentication Sub-option . . . . . . . . 4 4. Relay Agent Option Authentication Sub-option . . . . . . . . 4
4.1 Suboption Format . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Suboption Format . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 19 skipping to change at page 3, line 19
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2. DHCP Terminology 2. DHCP Terminology
This document uses the terms "DHCP server" (or "server") and "DHCP This document uses the terms "DHCP server" (or "server") and "DHCP
client" (or "client") as defined in RFC 2131. The term "DHCP relay client" (or "client") as defined in RFC 2131. The term "DHCP relay
agent" refers to a "BOOTP relay agent" as defined in RFC 2131. agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
3. Introduction 3. Introduction
DHCP (RFC 2131 [6]) provides IP addresses and configuration DHCP (RFC 2131 [8]) provides IP addresses and configuration
information for DHCP clients. It includes a relay agent capability information for DHCP clients. It includes a relay agent capability
(RFC 951 [7], RFC 1542 [8]), in which processes within the network (RFC 951 [9], RFC 1542 [10]), 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 like
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, using the relay agent information option, RFC 3046
[2]. The kind of information that a relay agent adds is often used [2]. The kind of information that a relay agent adds is often used
in the server's decision making about the addresses and configuration in the server's decision making about the addresses and configuration
parameters that the client should receive. The way that the relay parameters that the client should receive. The way that the relay
agent data is used in server decision-making tends to make that data agent data is used in server decision-making tends to make that data
very important, and highlights the importance of the trust very important, and 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) [11] only
secures communication between the DHCP client and server. Because secures 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 is to define methods that a relay The goals of this specification is to define methods that a relay
agent can use to: agent can use to:
1. protect the integrity of the data that the relay adds 1. protect the integrity of the data that the relay adds
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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 TSIG Authentication RFC. Other authentication protocols, like DNS TSIG
[10], use a key name. A key name is more flexible and potentially [12], use a key name. A key name is more flexible and potentially
more human-readable than a key id. DHCP servers may well be more human-readable than a key id. DHCP servers may well be
configured to use key names for DNS updates using TSIG, so it configured to use key names for DNS updates using TSIG, so it
might simplify DHCP server configuration if some of the key- might simplify DHCP server configuration if some of the key-
management for both protocols could be shared. 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 Named keys would require more physical space, and would entail
more complex suboption encoding and parsing implementations. more complex suboption encoding and parsing implementations.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
DISCUSSION: DISCUSSION:
This server behavior represents a slight variance from RFC 3046 This server behavior represents a slight variance from RFC 3046
[2], Section 2.2. The Authentication suboption is not echoed back [2], Section 2.2. The Authentication suboption is not echoed back
from the server to the relay: the server generates its own from the server to the relay: the server generates its own
suboption. suboption.
5. Use of IPsec to secure DHCP messages 5. Use of IPsec to secure DHCP messages
Relay agents and servers that exchange messages securely can use Relay agents and servers that exchange messages securely can use
IPsec mechanisms as described in this section. Relay agents and IPsec mechanisms [5] as described in this section. Relay agents and
servers MUST support manual configuration and installation of static servers MUST support manual configuration and installation of static
keys. If a client message is relayed through multiple relay agents, keys. If a client message is relayed through multiple relay agents,
each of the relay agents must have established independent, pairwise each of the relay agents must have established independent, pairwise
trust relationships. That is, if messages from client C will be trust relationships. That is, if messages from client C will be
relayed by relay agent A to relay agent B and then to the server, relayed by relay agent A to relay agent B and then to the server,
relay agents A and B must be configured to use IPSec for the messages relay agents A and B must be configured to use IPSec for the messages
they exchange, and relay agent B and the server must be configured to they exchange, and relay agent B and the server must be configured to
use IPSec for the messages they exchange. use IPSec for the messages they exchange.
Relay agents and servers that support secure relay agent to server or Relay agents and servers that support secure relay agent to server or
relay agent to relay agent communication, MUST include an IPsec relay agent to relay agent communication, MUST include an IPsec
implementation with the following restrictions: implementation with the following restrictions:
o The IPsec implementation MUST use ESP o The IPsec implementation MUST use ESP [6]
o Packet authentication MUST be applied o Packet authentication MUST be applied
o Encryption MAY be applied (i.e., NULL encryption can be used) o Encryption MAY be applied (i.e., NULL encryption can be used)
6. IANA Considerations 6. IANA Considerations
Section 4.1 defines a new suboption for the DHCP relay agent option, Section 4.1 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
skipping to change at page 13, line 21 skipping to change at page 13, line 21
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 fields. These number spaces are to be created and maintained by
IANA. 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 4.4.1. Additional algorithm values will be defined in Section 4.4.1. Additional algorithm values will be
allocated and assigned through IETF consensus, as defined in RFC 2434 allocated and assigned through IETF consensus, as defined in RFC 2434
[5]. [7].
The RDM identifier is a four-bit value. RDM value 0 is reserved. 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 RDM value 1 is assigned to the use of a monotonically increasing
counter value as defined in Section 4.2. Additional RDM values will counter value as defined in Section 4.2. Additional RDM values will
be allocated and assigned through IETF consensus, as defined in RFC be allocated and assigned through IETF consensus, as defined in RFC
2434 [5]. 2434 [7].
7. Security Considerations 7. Security Considerations
This specification describes two mechanisms that can be used to This specification describes two mechanisms that can be used to
provide authentication and message integrity protection to the provide authentication and message integrity protection to the
messages between DHCP relay agents and DHCP servers. messages between DHCP relay agents and DHCP servers.
The use of the authentication sub-option protocol imposes a new The use of the authentication sub-option protocol imposes a new
computational burden on relay agents and servers, because they must computational burden on relay agents and servers, because they must
perform cryptographic hash calculations when they send and receive perform cryptographic hash calculations when they send and receive
skipping to change at page 14, line 38 skipping to change at page 14, line 38
[2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001. January 2001.
[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] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April [4] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
1992. 1992.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
Informative References Informative References
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[7] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [9] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap [10] 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", [11] 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, [12] Vixie, P., Gudmundsson, O., Eastlake, 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.
Authors' Addresses Authors' Addresses
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Dr. 1414 Massachusetts Ave.
Chelmsford, MA 01824 Boxborough, MA 01719
USA USA
Phone: 978.244.8498 Phone: 978.936.1535
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: mellon@nominum.com EMail: mellon@nominum.com
Ralph Droms Ralph Droms
Cisco Systems, Inc. Cisco Systems, Inc.
300 Apollo Drive 1414 Massachusetts Ave.
Chelmsford, MA 01824 Boxborough, MA 01719
USA USA
Phone: +1 978 497 4733 Phone: +1 978.936.1674
EMail: rdroms@cisco.com EMail: rdroms@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
 End of changes. 

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