draft-ietf-dhc-auth-suboption-02.txt   draft-ietf-dhc-auth-suboption-03.txt 
DHC Working Group M. Stapp DHC Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: April 23, 2004 T. Lemon Expires: August 5, 2004 T. Lemon
Nominum, Inc. Nominum, Inc.
October 24, 2003 February 5, 2004
The Authentication Suboption for the DHCP Relay Agent Option The Authentication Suboption for the DHCP Relay Agent Option
<draft-ietf-dhc-auth-suboption-02.txt> <draft-ietf-dhc-auth-suboption-03.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 April 23, 2004. This Internet-Draft will expire on August 5, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The DHCP Relay Agent Information Option (RFC 3046[1]) 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 a new authentication suboption for that option specification defines an authentication suboption for that option
which supports source entity authentication and data integrity for which supports source entity authentication and data integrity for
relayed DHCP messages. The authentication suboption contains a relayed DHCP messages. The authentication suboption contains a
cryptographic signature in a payload derived from the option used in cryptographic signature in its payload.
DHCP Authentication (RFC 3118[9]).
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. 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . 11 11.1 Receiving Messages from Relay Agents . . . . . . . . . . . . 11
11.2 Sending Reply Messages to Relay Agents . . . . . . . . . . . 11 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 Protocol Vulnerabilities . . . . . . . . . . . . . . . . . . 12 13.1 Protocol Vulnerabilities . . . . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
1. Requirements Terminology 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[2]. document are to be interpreted as described in RFC 2119[2].
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[6]. The term "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. relay 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[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 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 forwarding it, using the relay-agent information option (RFC
3046[1]. The kind of information that relays add is often used in 3046[1]). The kind of information that relays add is often used in
the server's decision making about the addresses and configuration the 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 relay-agent data is used in server decision-making tends to make
that data very important, and highlights the importance of the trust that data 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)[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 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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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.
The DHC WG has developed two documents describing authentication of
DHCP relay agent options to accommodate the requirements of
different deployment scenarios: this document and Authentication of
Relay Agent Options Using IPSEC[11]. In deployments where IPsec is
readily available and pairwise keys can be managed efficiently, the
use of IPsec as described in that document may be appropriate. If
IPsec is not available or there are multiple relay agents for which
multiple keys must be managed, the protocol described in this
document may be appropriate. As is the case whenever two
alternatives are available, local network administration can choose
whichever is more appropriate. Because the relay agents and the DHCP
server are all in the same administrative domain, the appropriate
mechanism can be configured on all interoperating DHCP server
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 Normative References
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
skipping to change at page 13, line 18 skipping to change at page 13, line 32
[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, 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
(draft-ietf-dhc-relay-agent-ipsec-*.txt)", 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.1535 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: mellon@nominum.com EMail: Ted.Lemon@nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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