One document matched: draft-pruss-dhcp-auth-dsl-03.txt
Differences from draft-pruss-dhcp-auth-dsl-02.txt
Dynamic Host Configuration WG R. Pruss
Internet-Draft Cisco Systems
Intended status: Informational G. Zorn
Expires: November 19, 2008 Aruba Networks
R. Maglione
Telecom Italia
Y. Li
Huawei Technologies
May 18, 2008
Authentication Extensions for the Dynamic Host Configuration Protocol
draft-pruss-dhcp-auth-dsl-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 19, 2008.
Abstract
This document defines Dynamic Host Configuration Protocol (DHCP)
extensions that provide for end-user authentication prior to
configuration of the host. The primary applicability is within a
Digital Subscriber Line (DSL) Broadband network environment in order
to enable a smooth migration from the Point to Point Protocol (PPP).
Pruss, et al. Expires November 19, 2008 [Page 1]
Internet-Draft DHCP Authentication May 2008
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Architecture and Terminology . . . . . . . . . . . . . 5
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Protocol Operation for IPv4 . . . . . . . . . . . . . . . 6
5.2. Protocol Operation for IPv6 . . . . . . . . . . . . . . . 11
6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. DHCP Authentication Protocol Option . . . . . . . . . . . 15
6.2. EAP-Message Option . . . . . . . . . . . . . . . . . . . . 16
7. Messages for EAP operation . . . . . . . . . . . . . . . . . . 16
8. Fragmentaion . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Backwards Compatibility Considerations . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Message Authentication . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Pruss, et al. Expires November 19, 2008 [Page 2]
Internet-Draft DHCP Authentication May 2008
1. Introduction
This document defines DHCP Options and procedures that allow for an
Extensible Authentication Protocol (EAP) authentication exchange to
occur in DHCP in order to enable smooth migration from Point-to-Point
Protocol (PPP)[RFC1661] sessions to IP sessions in a DSL Broadband
network environment. Primary goals are integration of authentication
in such a way that it will operate seamlessly with existing RADIUS-
based Authentication, Authorization and Accounting (AAA)
infrastructure and Asynchronous Transfer Mode (ATM) or Ethernet based
DSL Networks. As such, only the termination points of PPP in the DSL
network are affected, both of which are devices that would logically
need to be updated in any transition from PPP to IP sessions.
It should be noted that [RFC3118] defines a mechanism that provides
authentication of individual DHCP messages. While this mechanism
does provide a method of authentication for a DHCP Client based on a
shared secret, it does not do so in a manner that can be seamlessly
integrated with existing RADIUS-based AAA infrastructure.
2. Problem Statement
Digital Subscriber Line (DSL) broadband service providers are
witnessing a shift in the "last-mile" aggregation technologies and
protocols which have traditionally been relied upon. Two primary
transitions are from ATM to Ethernet in the access network, and from
the PPP for multi-protocol framing and dynamic endpoint configuration
to direct encapsulation of IP and DHCP for dynamic endpoint
configuration for some devices. The term used by the DSL Forum for
the network state associated with an authorized subscriber (that is
using DHCP and IP rather than PPP) is "IP session" [WT-146]. While
these trends can be readily witnessed, neither are occurring
overnight. In addition, they are not necessarily implemented in
lock-step. Thus, one may find ATM-based and Ethernet-based access
networks running a combination of PPP sessions and IP sessions at any
given time, particularly during transition periods. These
coexistences will even occur for the same service subscriber.
Removing PPP, Point-to-Point Protocol over ATM (PPPoA) [RFC2364], and
Point-to-Point Protocol over Ethernet (PPPoE) [RFC2516] from the
subscriber access network is relatively straightforward in that most
of the properties that DSL providers are interested in going forward
are already present in DHCP and IP sessions. Luckily, there are some
capabilities of PPP which the market does not continue to demand.
For example, the Dynamic configuration in PPP for IPX or NETBEUI, for
example, is no longer of concern. Neither are the multi-link bonding
capabilities of PPP [RFC1990] commonly used on separate ISDN
Pruss, et al. Expires November 19, 2008 [Page 3]
Internet-Draft DHCP Authentication May 2008
B-channels, and the myriad of other features that PPP developed as
the "dial-based" access protocol of choice for framing,
authentication, and dynamic configuration for IP and other network
layer protocols. Missing from IP sessions and DHCP [RFC2131],
however, are isomorphic methods for user authentication and session
liveness probing (sometimes referred to as a session "keepalive").
For the latter, existence of a client using a given IP address can be
detected by a number of means, including Address Resolution Protocol
(ARP) [RFC0826], ICMP Echo/Echo Response [RFC0792], or Bidirectional
Forwarding Detection (BFD) [I-D.ietf-bfd-base]. This leaves
authentication as an open issue needing resolution. Specifically,
authentication based on a username and secret password must be
covered. This is something that in PPP always occurs before dynamic
configuration of an IP address and associated parameters.
While most DSL deployments utilize a username and password to
authenticate a subscriber and authorize access today, this is not the
only method for authentication that has been adopted when moving to
DHCP and IP sessions. "Option 82" [RFC3046] is commonly used with
DHCP as a credential to authenticate a given subscriber line and
authorize service. In this model, the DSL Access Node, which always
sits between the DHCP Client and Server, snoops DHCP messages as they
pass, and inserts pre-configured information for a given line (e.g.,
an ATM VPI/VCI, Ethernet VLAN, or other tag). That information,
while provided in clear text, traverses what is considered a
physically secured portion of the access network and is used to
determine (typically via a request to an AAA server) whether the DHCP
exchange can continue. This fits quite well with current DSL network
architecture, as long as the subscriber line itself is all that needs
be authorized. However, in some service models it is still necessary
for the subscriber to provide credentials directly.
From the perspective of the Network Access Server (NAS) where the
DHCP Server resides, the extensions defined in this document are
analogous to the commonly available "Option 82" method. The primary
difference between using Option 82 line configuration and a username
and password is that the authentication credentials are provided by
the subscriber rather than inserted by intervening network equipment.
Providing credentials from the subscriber rather than intervening
network equipment is particularly important for cases where
subscriber line information is unavailable, untrusted, or due to the
terms of the service changing at any time. Further, different
devices in the home may have different policies and require different
credentials. Migration scenarios where PPPoE and DHCP operate on the
same network for a period of time lend well to models which utilize
identical authentication and authorization credentials across the
different data plane encapsulations.
Pruss, et al. Expires November 19, 2008 [Page 4]
Internet-Draft DHCP Authentication May 2008
3. Network Architecture and Terminology
The DSL Forum defines its ATM-based network architecture in [TR-059]
and Ethernet-based network architecture in [TR-101]. The extensions
for DHCP defined in this document are designed to work identically on
Ethernet or ATM architectures. The diagram in Figure 1 and following
terminology will be used throughout:
+-----------+ +------------+
| DHCP | | AAA/RADIUS |
| Server | | Server |
+-----------+ +------------+
| |
| |
Sub. +-----+ +--------+ | +-----+ +----------+
Home ---| HGW |---| | +---------| | | |
Network +-----+ | Access | | | | |
| Node |--/Aggregation\--| NAS |---| Internet |
Sub. +-----+ | |--\ Network /--| | | |
Home ---| HGW |---| | | | | |
Network +-----+ +--------+ +-----+ +----------+
| |
|----------DSL Access Network --------|
Figure 1: DSL Network Architecture
o Access Node (AN): Network device, usually located at a service
provider central office or street cabinet, that terminates Access
Loop connections from Subscribers. In case the Access Loop is a
Digital Subscriber Line (DSL), this is often referred to as a DSL
Access Multiplexer (DSLAM). The AN may support one or more Access
Loop technologies and allow them to inter-work with a common
aggregation network technology.
o Network Access Server (NAS): Network device that aggregates
multiplexed Subscriber traffic from a number of Access Nodes. The
NAS plays a central role in per-subscriber policy enforcement and
QoS. Often referred to as a Broadband Network Gateway (BNG) or
Broadband Remote Access Server (BRAS). A detailed definition of
the NAS is given in [RFC2881].
o The Home Gateway (HGW) connects the different Customer Premises
Equipment (CPE) to the Access Node and the access network. In
case of DSL, the HGW is a DSL Network Termination (NT) that could
either operate as a layer 2 bridge or as a layer 3 router. In the
latter case, such a device is also referred to as a Routing
Gateway (RG).
Pruss, et al. Expires November 19, 2008 [Page 5]
Internet-Draft DHCP Authentication May 2008
o Referring to the DSL network architecture depicted in Figure 1,
PPP (via PPPoA [RFC2364] or PPPoE [RFC2516]) operates over the DSL
Access Network between the NAS and a device behind the HGW, or
between the NAS and the HGW itself. The DHCP Client resides
either on a home network device or the HGW, and the DHCP Server
protocol state machine may reside fully on the NAS. The NAS
obtains per-subscriber client configuration information either
locally, relayed from a DHCP server or from the AAA infrastructure
(which itself may consult external DHCP servers if necessary)
after authentication is successfully completed.
4. Applicability Statement
The primary target for this extension is for DSL service provider
networks where PPP is being phased out to be replaced by native IP
and DHCP, or where new devices are being added which will not utilize
PPP. Very specific assumptions have been made with respect to the
security model, operational methods, and integration requirements for
existing AAA mechanisms during the design. It is understood that
this mechanism may not be generally applicable in this form for all
network environments where DHCP is deployed, though perhaps elements
of it may be used to develop a more generic approach while still
meeting the specific requirements set out by the DSL network
architecture. Earlier revisions of this document included a method
to embed PPP CHAP [RFC1994] authentication as Options in existing
DHCP messages. This method has been abandoned due to security
vulnerabilities in CHAP, as well as a lack of extensibility. This
document bases its authentication on EAP [RFC3748] which can be used
with a large number of different authentication methods, including
one backwards compatible with existing PPP CHAP.
5. Protocol Operation
This section describes the protocol operation for EAP within DHCPv4
[RFC2131] and DHCPv6 [RFC3315]. Options and message specifications
used in these operation descriptions are detailed in later sections.
If multiple DHCP exchanges are occurring with multiple servers, both
IPv4 and IPv6 each needs to authenticate separately.
5.1. Protocol Operation for IPv4
It is essential that the user/node authentication occurs before the
assignment of an IP address and, further, that the assignment of the
address depends upon the details of the successful authentication. .
DHCP [RFC2131] is widely used as an address assignment method (among
Pruss, et al. Expires November 19, 2008 [Page 6]
Internet-Draft DHCP Authentication May 2008
other things); EAP [RFC3748] has been widely adapted for
authentication purposes, especially in those types of networks where
DHCP is also used. This section describes how to combine the two in
order to provide both strong authentication and authenticated address
assignment in an efficient manner.
Two new DHCPEAP messages are used in the DHCP message flow to support
the new EAP phase which occurs before a DHCPOFFER is sent by the
Server. This message is used to integrate authentication methods
supported by EAP, including CHAP and any other "in the clear"
password mechanisms (for example, to support One-Time Password
mechanisms), or to carry other EAP methods. EAP is widely used in
other environments, outside of DSL Broadband, including 802.11
"Wi-Fi" access networks but could be used in future DSL Broadband
deployments.
To request the assignment of an IPv4 address with authentication, a
client first locates a DHCP server, then authenticates using EAP and
then requests the assignment of an address and other configuration
information from the server. The client sends a DHCP Discover
message with an option specifying the authentication protocol as EAP
to find an available DHCP server. Any server that can that can
authenticate and address it responds with a DHCPEAP-REQ message.
Servers which support DHCP authentication will respond with a
DHCPEAP-REQ message. The client may receive one or more DHCPEAP-REQ
messages from one or more DHCP Servers. The Client chooses one to
reply to, and sends a DHCPEAP-RES message, silently discarding
DHCPEAP-REQ messages from other Servers. The DHCPEAP-RES and
DHCPEAP-REQ messages contain EAP packets which facilitate the EAP
authentication exchange. The exchange may occur between the DHCP
Client and DHCP Server embedded within a NAS, or be carried
transparently to the AAA Server. Upon successful completion of the
authentication phase, the DHCP server sends a DHCPOFFER with the
appropriate IP configuration for the authenticated user. The client
then follows the normal DHCP procedures of a successful DHCP exchange
by sending a DHCPREQUEST, followed by a DHCPACK from the Server.
If the authentication phase fails (e.g., the user does not provide
appropriate credentials), then according to configured policy the
DHCP Client is either denied any IP configuration with the DHCP
Server sending a DHCPNAK accordingly, or the DHCP Client is given a
"limited access" configuration profile and the DHCP exchange
continues as if the authentication was successful.
A typical message flow proceeds as shown in Figure 2:
Pruss, et al. Expires November 19, 2008 [Page 7]
Internet-Draft DHCP Authentication May 2008
(HGW) (NAS) (AAA)
DHCP Client DHCP Server/ RADIUS Server
DHCPDISCOVER ------->
(w/DHCP-auth-proto EAP)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
(The last four messages repeat until EAP Success or EAP fail)
(DHCP messages continue normally from
this point forward if successful)
<------- DHCPOFFER (w/EAP Success Message)
(w/yiaddr)
DHCPREQUEST ------->
<------- DHCPACK
Figure 2: DHCP Message Flow with DHCPEAP messages
The retransmission is handled by EAP as per Section 4.1 in [RFC3748].
Pruss, et al. Expires November 19, 2008 [Page 8]
Internet-Draft DHCP Authentication May 2008
The message exchange presented in the figure is an example of simple
one-way user authentication, e.g. the Server verifies the credentials
of the HGW Client. The client indicates the ability to have an EAP
exchange and the NAS (which takes on the EAP authenticator role)
initiates the first EAP request to the DHCP Client (which takes on
the EAP supplicant role). DHCP-REQ and DHCP-RES does not suggest a
coupling between the EAP state machine and the DHCP authentication
phase state machine. They only indicate the direction of the
message, either from Client to Server or Server to Client.
When the NAS is acting as a DHCP Relay the BRAS may split the EAP
Messages from DHCP and perform the AAA authentication with an AAA
server. This allows use of existing DHCP servers and existing AAA
servers.
An example message flow for DHCP Relay proceeds as shown in Figure 3:
Pruss, et al. Expires November 19, 2008 [Page 9]
Internet-Draft DHCP Authentication May 2008
(HGW) (NAS) (AAA) (DHCP)
DHCP Client AAA Client RADIUS Server DHCP Server
DHCPDISCOVER ------->
(w/DHCP-auth-proto EAP)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
(The last four messages repeat until EAP Success or EAP fail)
(DHCP messages continue normally from
this point forward if successful)
DHCPDISCOVER ------------------------------>
(w/RADIUS attributes suboption)
<----------------------------- DHCPOFFER
<------- DHCPOFFER (w/EAP Success Message)
(w/yiaddr)
DHCPREQUEST ------->
<------- DHCPACK
Pruss, et al. Expires November 19, 2008 [Page 10]
Internet-Draft DHCP Authentication May 2008
Figure 3: DHCP Authentication Message Flow with DHCP relay NAS
When the DHCP relay agent in the NAS receives a DHCP message from the
client, it MAY append a DHCP Relay Agent Information option
containing the RADIUS Attributes suboption, along with any other
suboptions it is configured to supply. The RADIUS Attributes
suboption is defined in [RFC4014]
DHCP Authentication uses two DHCP options:
o DHCP Authentication Protocol Option in the DHCPDISCOVER to specify
the type of authentication exchange.
o EAP-Message Option to carry the EAP data in the DHCPEAP messages.
5.2. Protocol Operation for IPv6
This section describes the protocol operation for extending Dynamic
Host Configuration Protocol for IPv6 [RFC3315] for an EAP phase.
The same as the previous section on extending DHCP in IPv4 new DHCP
messages, DHCPEAP-REQ and DHCPEAP-RES are used to support EAP
authentication before host configuration occurs. The mechanisms
described here follow a similar methodology as that for DHCPv4
described in Section 5.1.
The client sends a Solicit message with an Option specifying the
session authentication protocol as EAP to the
All_DHCP_Relay_Agents_and_Servers address to find available DHCP
servers. Any server that can authenticate and address it responds
with a DHCPEAP-REQ message.
The client may receive one or more DHCPEAP-REQ messages from one or
more DHCP Servers. The Client chooses one to reply to, and sends a
DHCPEAP-RES message, silently discarding DHCPEAP-REQ messages from
other Servers. The DHCPEAP-RES and DHCPEAP-REQ messages contain EAP
packets which facilitate the EAP authentication exchange. The
exchange may occur between the DHCP Client and DHCP Server embedded
within a NAS, or be carried transparently to the AAA Server. Upon
successful completion of the authentication phase, the DHCP server
sends a ADVERTISE with the appropriate configuration for the
authenticated user. The client then follows the normal DHCP
procedures of a successful DHCP exchange by sending a REQUEST,
followed by a DHCPACK from the Server.
If the authentication phase fails (e.g., the user does not provide
appropriate credentials), then according to configured policy the
DHCP Client is either denied any IP configuration with the DHCP
Pruss, et al. Expires November 19, 2008 [Page 11]
Internet-Draft DHCP Authentication May 2008
Server sending a NAK accordingly, or the DHCP Client is given a
"limited access" configuration profile and the DHCP exchange
continues as if the authentication was successful.
. A typical message flow proceeds as shown in Figure 4:
Pruss, et al. Expires November 19, 2008 [Page 12]
Internet-Draft DHCP Authentication May 2008
(HGW) (NAS) (AAA)
DHCP Client DHCP Server/ RADIUS Server
SOLICIT ------->
(w/DHCP-auth-proto EAP)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
(The last four messages repeat until EAP Success or EAP fail)
(DHCP messages continue normally from
this point forward if successful)
<------- ADVERTISE (w/EAP Success Message)
REQUEST ------->
<------- REPLY
Figure 4: DHCP IPv6 with DHCPEAP message
The retransmission is handled by EAP as per Section 4.1 in [RFC3748].
Pruss, et al. Expires November 19, 2008 [Page 13]
Internet-Draft DHCP Authentication May 2008
The message following this exchange is a ADVERTISE, sent unchanged by
the Server. A typical message flow proceeds as shown in Figure 5:
(HGW) (NAS) (AAA) (DHCP)
DHCP Client AAA Client RADIUS Server DHCP Server
SOLICIT ------->
(w/DHCP-auth-proto EAP)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
<------- DHCPEAP-REQ
(w/EAP Message)
DHCPEAP-RES ------->
(w/EAP Message)
RADIUS Access-Request ------->
(w/EAP Message)
<-------- RADIUS
Access-Accept (w/EAP Message)
(Access-Reject (w/EAP Message)
if unsuccessful)
(The last four messages repeat until EAP Success or EAP fail)
(DHCP messages continue normally from
this point forward if successful)
RELAY-FORW ------------------------------>
(w/RADIUS attributes suboption)
<----------------------------- RELAY-REPL
<------- ADVERTISE (w/EAP Success Message)
Pruss, et al. Expires November 19, 2008 [Page 14]
Internet-Draft DHCP Authentication May 2008
REQUEST ------->
<------- REPLY
Figure 5: Message Flow with new message and a DHCP relay
When the DHCP relay agent in the NAS receives a DHCP message from the
client, it MAY append a DHCP Relay Agent Information option
containing the RADIUS Attributes suboption, along with any other
suboptions it is configured to supply. The RADIUS Attributes
suboption is defined in [RFC4014]
DHCP Authentication uses two DHCP options:
o DHCP Authentication Protocol Option in the SOLICIT to specify the
type of authentication exchange.
o EAP-Message Option to carry the EAP data in the DHCPEAP messages.
6. DHCP Options
Two DHCP Options are defined in this section. The first DHCP
Authentication Protocol Option is originated from the client in the
DHCPDISCOVER and SOLICIT to specify which authentication the client
supports.
6.1. DHCP Authentication Protocol Option
The DHCPAUTH-Protocol option is sent from the DHCP Client to the DHCP
Server to indicate the authentication algorithm the client prefers.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Code | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
Figure 6: DHCP Authentication Protocol Option
DHCP Code: TBA-1 (DHCPAUTH-Protocol)
Length: 3
Authentication-Protocol
Pruss, et al. Expires November 19, 2008 [Page 15]
Internet-Draft DHCP Authentication May 2008
C227 (HEX) for Extensible Authentication Protocol (EAP)
Algorithm
The Algorithm field is one octet and indicates the
authentication method to be used with the Method
6.2. EAP-Message Option
The format of the EAP-Message option used in Protocol Operation for
IPv4 is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Code | Length | m...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Message Option
The maximum size of a DHCP option is 255 octets. While in some cases
(e.g., EAP MD5-Challenge [RFC3748]) a complete EAP message may fit in
a single DHCP option, in general this is not the case. If an EAP
message is too large to fit into a single DHCP option, the method
defined in [RFC3396] MUST be used to split the EAP message into
separate options for transmission. Similarly, EAP assumes a minimum
MTU of 1020 octets while the minimum DHCP packet size is 576 octets,
including 312 octets reserved for options. A DHCP client including
the EAP-Message option SHOULD also include the 'maximum DHCP message
size' option [RFC2132] to set a suitable DHCP message size.
If a DHCP message is received containing more than one EAP-Message
option, the method defined in [RFC3396] MUST be used to reassemble
the separate options into the original EAP message. A DHCP server
receiving an EAP message MAY forward it via a AAA protocol (such as
RADIUS [RFC2865] [RFC3579] or Diameter [RFC3588]] [RFC4072]).
7. Messages for EAP operation
The DHCPEAP messages follow the format for DHCP messages defined in
RFC 2131 [RFC2131]. This new message is identified by the presence
of a DHCP Message Type option, which encodes DHCPEAP-REQ or DHCPEAP-
RES message type. Other fields in the DHCP message header, such as
siaddr and fname, are left unused.
The authentication data in a DHCPAUTH message is carried in a EAP-
Messsage option EAP-Message Option.
Pruss, et al. Expires November 19, 2008 [Page 16]
Internet-Draft DHCP Authentication May 2008
8. Fragmentaion
Encapsulating EAP messages within DHCP raises the question of whether
there are potential difficulties with respect to the MTU sizes of the
EAP and DHCP messages, as well as the underlying link MTU.
EAP as defined in [RFC3748] Section 3.1 says:
[4] Minimum MTU. EAP is capable of functioning on lower layers that
provide an EAP MTU size of 1020 octets or greater.
DHCP as defined in [RFC2131] Section 2 says:
... This requirement implies that a DHCP client must be prepared to
receive a message of up to 576 octets, the minimum IP datagram size
an IP host must be prepared to accept [3]. DHCP clients may
negotiate the use of larger DHCP messages through the 'maximum DHCP
message size' option. The options field may be further extended into
the 'file' and 'sname' fields.
If we assume EAP MTU-sized packets, the overhead to pack an EAP
packet into DHCP options is 2*(1020/255), or 8 octets. Adding the
DHCP header (240 octets), UDP (8 octets), and the IP header (20
octets) gives 278 octets total overhead. Since the Ethernet
effective MTU is 1500 octets, this 278 octet overhead leaves the DHCP
protocol with 1222 octets to carry EAP. This space is over 200
octets more than the EAP MTU of 1020 octets.
If we add the SNAME and CHADDR fields to the option pool, then there
are nearly 400 octets available for DHCP options in an Ethernet MTU-
sized DHCP packet, encapsulating EAP.
In short, when the 'maximum DHCP message size' option is used by the
client, there is no problem carrying in EAP over DHCP. i.e. clients
capable of performing EAP over DHCP should also advertise a maximum
message that is capable of carrying EAP over DHCP.
9. Backwards Compatibility Considerations
This section is aimed at describing interoperability scenarios
involving HGW and NAS with or without DHCP Authentication mechanism
support in order to analyze compatibility issues that could be faced
between newer and older products during the introduction of the DHCP
Authentication functionally in current implemented network
environments.
Scenario 1: Both HGW and NAS do not support DHCP Authentication
Pruss, et al. Expires November 19, 2008 [Page 17]
Internet-Draft DHCP Authentication May 2008
In this case the authentication process does not start, thus
traditional DHCP message flow applies.
Scenario 2: HGW does not support DHCP Authentication and NAS supports
DHCP Authentication
In this case the DHCP client does not start DHCP Authentication
transaction, NAS MAY decide to respond to HGW without using DHCP
Authentication, falling back to traditional DHCP message flow and
assigning different network resources.
Scenario 3: HGW supports the DHCP Authentication and NAS does not
support DHCP Authentication.
In this case the DHCP client inserts in the DHCPDISCOVER message sent
to NAS, the DHCP Authentication Protocol Option described in the
draft in order to communicate the NAS that it is able to perform
authentication and for indicating the authentication algorithm
preferred by the client. NAS on receiving a DHCPDISCOVER with
unknown option silently discards unknown message. Alternatively NAS
MAY ignore the unknown option, but still process the message and then
reply to the DHCP client with traditional response. The HGW, that
has upgraded software, realizes that the NAS does not support DHCP
Authentication and can reverts back to normal DHCP message flow.
Scenario 4 Both HGW and NAS support DHCP Authentication
In this case DHCP client inserts in the DHCPDISCOVER message sent to
NAS, the DHCP Authentication Protocol Option in order to communicate
the NAS that it is able to perform authentication and for indicating
the authentication algorithm preferred by the client, NAS replies
according to the message flow described in this draft.
The following table summarizes the behavior in the 4 described
scenarios:
Pruss, et al. Expires November 19, 2008 [Page 18]
Internet-Draft DHCP Authentication May 2008
+---------------+---------------+-----------------------------------+
| DHCP Auth | DHCP Auth | Result |
| support on | support on | |
| HGW | NAS | |
+---------------+---------------+-----------------------------------+
| without | without | No Authentication |
| support | support | |
| without | with support | Client does not start auth, thus |
| support | | no authentication transaction |
| with support | without | NAS silently discards unknown |
| | support | message/option |
| with support | with support | Draft works as outlined |
+---------------+---------------+-----------------------------------+
Table 1: Compatibility Scenarios
10. Security Considerations
10.1. Message Authentication
RFC 3118 provides a mechanism to cryptographically protect DHCP
messages using a key, K, shared between a DHCP client and Server,
however no mechanism is defined to manage these keys. Authentication
exchanges based on EAP have been built into authentication portions
of network access protocols such as PPP, 802.1X, PANA, IKEv2, and now
DHCP. EAP methods may provide for the derivation of shared key
material, the MSK and the EMSK, on the EAP peer and EAP server. This
dynamic key generation enables [RFC3118] protection and allows modes
of operation where messages are protected from DHCP client to DHCP
relay which previously would be difficult to manage.
A future document will look at how to derive the key, K, from the
EMSK resulting from an EAP exchange and at how this mechanism
interacts with the DHCP authentication or any EAP authentication
prior to DHCP.
11. IANA Considerations
This specification requires three values to be assigned by IANA.
Two are "BOOTP Vendor Extensions and DHCP Options"
Pruss, et al. Expires November 19, 2008 [Page 19]
Internet-Draft DHCP Authentication May 2008
TBA-1: (DHCPAUTH-Protocol)
TBA-2: (DHCPAUTH-Data)
Two DHCP Message Type 53 Values - per [RFC2132], for DHCPEAP-REQ AND
DHCPEAP-RES message types.
12. Acknowledgements
Many thanks to Carlos Pignataro for help editing this document.
Thanks to Alan DeKok, Wojciech Dec, Eric Voit, Mark Townsley and
Ralph Droms for help with this document.
Thanks to Amy Zhao for her draft on DHCP Authentication and helping
with laying the ground for this document.
13. References
13.1. Normative References
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-08 (work in progress),
March 2008.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Pruss, et al. Expires November 19, 2008 [Page 20]
Internet-Draft DHCP Authentication May 2008
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model",
RFC 2881, July 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Pruss, et al. Expires November 19, 2008 [Page 21]
Internet-Draft DHCP Authentication May 2008
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication
Dial-In User Service (RADIUS) Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent
Information Option", RFC 4014, February 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, January 2006.
[TR-059] DSL Forum, "DSL Evolution - Architecture Requirements for
the Support of QoS-Enabled IP Services", TR 059,
September 2003.
[TR-101] DSL Forum, "Migration to Ethernet Based DSL Aggregation",
TR 101, April 2006.
[WT-146] DSL Forum, "Internet Protocol (IP) Sessions", WT 146 (work
in progress), April 2007.
Authors' Addresses
Richard Pruss
Cisco Systems
80 Albert Street
Brisbane, Queensland 4000
Australia
Phone: +61 7 3238 8228
Fax: +61 7 3211 3889
Email: ric@cisco.com
Pruss, et al. Expires November 19, 2008 [Page 22]
Internet-Draft DHCP Authentication May 2008
Glen Zorn
Aruba Networks
1322 Crossman Avenue
Sunnyvale, CA 94089-1113
USA
Email: gwz@arubanetworks.com
Roberta Maglione
Telecom Italia
Via G. Reiss Romoli 274
Torino, 10148
Italy
Phone: +39 0112285007
Fax:
Email: roberta.maglione@telecomitalia.it
URI:
Li Yizhou
Huawei Technologies
No. 91 Baixia Rd
Nanjing, 210001
China
Phone: +86-25-84565471
Fax:
Email: liyizhou@huawei.com
URI:
Pruss, et al. Expires November 19, 2008 [Page 23]
Internet-Draft DHCP Authentication May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Pruss, et al. Expires November 19, 2008 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 14:02:33 |