One document matched: draft-pruss-dhcp-auth-dsl-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes" ?>
<rfc category="info" docName="draft-pruss-dhcp-auth-dsl-03" ipr="full3978">
<front>
<title abbrev="DHCP Authentication">Authentication Extensions for the
Dynamic Host Configuration Protocol</title>
<author fullname="Richard Pruss" initials="R." surname="Pruss">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>80 Albert Street</street>
<city>Brisbane</city>
<code>4000</code>
<region>Queensland</region>
<country>Australia</country>
</postal>
<phone>+61 7 3238 8228</phone>
<facsimile>+61 7 3211 3889</facsimile>
<email>ric@cisco.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G.W." surname="Zorn">
<organization>Aruba Networks</organization>
<address>
<postal>
<street>1322 Crossman Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1113</code>
<country>USA</country>
</postal>
<email>gwz@arubanetworks.com</email>
</address>
</author>
<author fullname="Roberta Maglione" initials="R." surname="Maglione">
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli 274</street>
<city>Torino</city>
<region></region>
<code>10148</code>
<country>Italy</country>
</postal>
<phone>+39 0112285007</phone>
<facsimile></facsimile>
<email>roberta.maglione@telecomitalia.it</email>
<uri></uri>
</address>
</author>
<author fullname="Li Yizhou" initials="Y." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 91 Baixia Rd</street>
<city>Nanjing</city>
<region></region>
<code>210001</code>
<country>China</country>
</postal>
<phone>+86-25-84565471</phone>
<facsimile></facsimile>
<email>liyizhou@huawei.com</email>
<uri></uri>
</address>
</author>
<date day="18" month="May" year="2008" />
<area>Internet Area</area>
<!-- Using the acronym to keep idnits happy
<workgroup>Dynamic Host Configuration Working Group</workgroup>
-->
<workgroup>Dynamic Host Configuration WG</workgroup>
<keyword>DHCP</keyword>
<keyword>EAP</keyword>
<keyword>PPP</keyword>
<keyword>CHAP</keyword>
<keyword>Authentication</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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).</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>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)<xref target="RFC1661"></xref> 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.</t>
<t>It should be noted that <xref target="RFC3118"></xref> 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.</t>
</section>
<section anchor="Problem" title="Problem Statement">
<t>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" <xref target="WT-146"></xref>. 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.</t>
<t>Removing PPP, Point-to-Point Protocol over ATM (PPPoA) <xref
target="RFC2364"></xref>, and Point-to-Point Protocol over Ethernet
(PPPoE) <xref target="RFC2516"></xref> 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 <xref
target="RFC1990"></xref> commonly used on separate ISDN 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 <xref target="RFC2131"></xref>, 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) <xref
target="RFC0826"></xref>, ICMP Echo/Echo Response <xref
target="RFC0792"></xref>, or Bidirectional Forwarding Detection (BFD)
<xref target="I-D.ietf-bfd-base"></xref>. 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.</t>
<t>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" <xref target="RFC3046"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="Architecture"
title="Network Architecture and Terminology">
<t>The DSL Forum defines its ATM-based network architecture in <xref
target="TR-059"></xref> and Ethernet-based network architecture in <xref
target="TR-101"></xref>. The extensions for DHCP defined in this
document are designed to work identically on Ethernet or ATM
architectures. The diagram in <xref target="Fig1"></xref> and following
terminology will be used throughout: <figure anchor="Fig1"
title="DSL Network Architecture">
<preamble></preamble>
<artwork><![CDATA[
+-----------+ +------------+
| DHCP | | AAA/RADIUS |
| Server | | Server |
+-----------+ +------------+
| |
| |
Sub. +-----+ +--------+ | +-----+ +----------+
Home ---| HGW |---| | +---------| | | |
Network +-----+ | Access | | | | |
| Node |--/Aggregation\--| NAS |---| Internet |
Sub. +-----+ | |--\ Network /--| | | |
Home ---| HGW |---| | | | | |
Network +-----+ +--------+ +-----+ +----------+
| |
|----------DSL Access Network --------| ]]></artwork>
<postamble></postamble>
</figure> <list style="symbols">
<t>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.</t>
<t>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 <xref target="RFC2881"></xref>.</t>
<t>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).</t>
<t>Referring to the DSL network architecture depicted in <xref
target="Fig1"></xref>, PPP (via PPPoA <xref target="RFC2364"></xref>
or PPPoE <xref target="RFC2516"></xref>) 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.</t>
</list></t>
</section>
<section anchor="Applicability" title="Applicability Statement">
<t>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 <xref
target="RFC1994"></xref> 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 <xref target="RFC3748"></xref> which can be used
with a large number of different authentication methods, including one
backwards compatible with existing PPP CHAP.</t>
</section>
<section anchor="Protocol" title="Protocol Operation">
<t>This section describes the protocol operation for EAP within DHCPv4
<xref target="RFC2131"></xref> and DHCPv6 <xref
target="RFC3315"></xref>. Options and message specifications used in
these operation descriptions are detailed in later sections.</t>
<t>If multiple DHCP exchanges are occurring with multiple servers, both
IPv4 and IPv6 each needs to authenticate separately.</t>
<section anchor="Protocol-IPv4" title="Protocol Operation for IPv4">
<t>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 <xref target="RFC2131"></xref> is widely used as an address
assignment method (among other things); EAP <xref
target="RFC3748"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>A typical message flow proceeds as shown in <xref
target="Fig2"></xref>: <figure anchor="Fig2"
title="DHCP Message Flow with DHCPEAP messages">
<preamble></preamble>
<artwork><![CDATA[
(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]]></artwork>
<postamble></postamble>
</figure>The retransmission is handled by EAP as per Section 4.1 in
<xref target="RFC3748"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>An example message flow for DHCP Relay proceeds as shown in <xref
target="Fig3"></xref>: <figure anchor="Fig3"
title="DHCP Authentication Message Flow with DHCP relay NAS">
<preamble></preamble>
<artwork><![CDATA[
(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]]></artwork>
<postamble></postamble>
</figure>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 <xref target="RFC4014"></xref></t>
<t>DHCP Authentication uses two DHCP options:<list style="symbols">
<t><xref format="title" target="DHCP-Auth-Proto"></xref> in the
DHCPDISCOVER to specify the type of authentication exchange.</t>
<t><xref format="title" target="EAP-Auth-Data"></xref> to carry
the EAP data in the DHCPEAP messages.</t>
</list></t>
</section>
<section anchor="Protocol-IPv6" title="Protocol Operation for IPv6">
<t>This section describes the protocol operation for extending Dynamic
Host Configuration Protocol for IPv6 <xref target="RFC3315"></xref>
for an EAP phase.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 NAK accordingly, or the DHCP Client is given a "limited
access" configuration profile and the DHCP exchange continues as if
the authentication was successful.</t>
<t>. A typical message flow proceeds as shown in <xref
target="Fig4"></xref>: <figure anchor="Fig4"
title="DHCP IPv6 with DHCPEAP message">
<preamble></preamble>
<artwork><![CDATA[
(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]]></artwork>
<postamble></postamble>
</figure>The retransmission is handled by EAP as per Section 4.1 in
<xref target="RFC3748"></xref>.</t>
<t>The message following this exchange is a ADVERTISE, sent unchanged
by the Server. A typical message flow proceeds as shown in <xref
target="Fig5"></xref>: <figure anchor="Fig5"
title="Message Flow with new message and a DHCP relay">
<preamble></preamble>
<artwork><![CDATA[
(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)
REQUEST ------->
<------- REPLY]]></artwork>
<postamble></postamble>
</figure></t>
<t>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 <xref target="RFC4014"></xref></t>
<t>DHCP Authentication uses two DHCP options:<list style="symbols">
<t><xref format="title" target="DHCP-Auth-Proto"></xref> in the
SOLICIT to specify the type of authentication exchange.</t>
<t><xref format="title" target="EAP-Auth-Data"></xref> to carry
the EAP data in the DHCPEAP messages.</t>
</list></t>
</section>
</section>
<section anchor="DHCP-Options" title="DHCP Options">
<t>Two DHCP Options are defined in this section. The first <xref
format="title" target="DHCP-Auth-Proto"></xref> is originated from the
client in the DHCPDISCOVER and SOLICIT to specify which authentication
the client supports.</t>
<section anchor="DHCP-Auth-Proto"
title="DHCP Authentication Protocol Option">
<t>The DHCPAUTH-Protocol option is sent from the DHCP Client to the
DHCP Server to indicate the authentication algorithm the client
prefers.</t>
<t><figure anchor="Fig6" title="DHCP Authentication Protocol Option">
<preamble></preamble>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Code | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure> <list hangIndent="3" style="empty">
<t>DHCP Code: TBA-1 (DHCPAUTH-Protocol)</t>
<t>Length: 3</t>
<t>Authentication-Protocol <list hangIndent="3" style="empty">
<t>C227 (HEX) for Extensible Authentication Protocol (EAP)</t>
</list></t>
<t>Algorithm <list hangIndent="3" style="empty">
<t>The Algorithm field is one octet and indicates the
authentication method to be used with the Method</t>
</list></t>
</list></t>
</section>
<section anchor="EAP-Auth-Data" title="EAP-Message Option">
<t>The format of the EAP-Message option used in <xref format="title"
target="Protocol-IPv4"></xref> is as follows:<figure anchor="Fig10"
title="EAP-Message Option">
<preamble></preamble>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Code | Length | m...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure> The maximum size of a DHCP option is 255 octets. While in
some cases (e.g., EAP MD5-Challenge <xref target="RFC3748"></xref>) 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 <xref target="RFC3396"></xref> 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 <xref
target="RFC2132"></xref> to set a suitable DHCP message size.</t>
<t>If a DHCP message is received containing more than one EAP-Message
option, the method defined in <xref target="RFC3396"></xref> 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 <xref target="RFC2865"></xref> <xref
target="RFC3579"></xref> or Diameter <xref target="RFC3588"></xref>]
<xref target="RFC4072"></xref>).</t>
</section>
</section>
<section anchor="New-Messages" title="Messages for EAP operation">
<t>The DHCPEAP messages follow the format for DHCP messages defined in
<xref target="RFC2131">RFC 2131</xref>. 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.</t>
<t>The authentication data in a DHCPAUTH message is carried in a
EAP-Messsage option <xref format="title"
target="EAP-Auth-Data"></xref>.</t>
</section>
<section title="Fragmentaion">
<t>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.</t>
<t>EAP as defined in <xref target="RFC3748"></xref> Section 3.1
says:</t>
<t>[4] Minimum MTU. EAP is capable of functioning on lower layers that
provide an EAP MTU size of 1020 octets or greater.</t>
<t>DHCP as defined in <xref target="RFC2131"></xref> Section 2 says:</t>
<t>... 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Compatibility"
title="Backwards Compatibility Considerations">
<t>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.</t>
<t>Scenario 1: Both HGW and NAS do not support DHCP Authentication</t>
<t>In this case the authentication process does not start, thus
traditional DHCP message flow applies.</t>
<t>Scenario 2: HGW does not support DHCP Authentication and NAS supports
DHCP Authentication</t>
<t>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.</t>
<t>Scenario 3: HGW supports the DHCP Authentication and NAS does not
support DHCP Authentication.</t>
<t>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.</t>
<t>Scenario 4 Both HGW and NAS support DHCP Authentication</t>
<t>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.</t>
<t>The following table summarizes the behavior in the 4 described
scenarios:</t>
<texttable anchor="Table" title="Compatibility Scenarios">
<preamble></preamble>
<ttcol>DHCP Auth support on HGW</ttcol>
<ttcol>DHCP Auth support on NAS</ttcol>
<ttcol>Result</ttcol>
<c>without support</c>
<c>without support</c>
<c>No Authentication</c>
<c>without support</c>
<c>with support</c>
<c>Client does not start auth, thus no authentication transaction</c>
<c>with support</c>
<c>without support</c>
<c>NAS silently discards unknown message/option</c>
<c>with support</c>
<c>with support</c>
<c>Draft works as outlined</c>
<postamble></postamble>
</texttable>
<t></t>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Message Authentication ">
<t>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 <xref target="RFC3118"></xref>
protection and allows modes of operation where messages are protected
from DHCP client to DHCP relay which previously would be difficult to
manage.</t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification requires three values to be assigned by IANA.</t>
<t>Two are "BOOTP Vendor Extensions and DHCP Options" <list
hangIndent="3" style="empty">
<t><list counter="TBA" hangIndent="7" style="format TBA-%d:">
<t>(DHCPAUTH-Protocol)</t>
<t>(DHCPAUTH-Data)</t>
</list></t>
</list>Two DHCP Message Type 53 Values - per [RFC2132], for
DHCPEAP-REQ AND DHCPEAP-RES message types.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Carlos Pignataro for help editing this document.</t>
<t>Thanks to Alan DeKok, Wojciech Dec, Eric Voit, Mark Townsley and
Ralph Droms for help with this document.</t>
<t>Thanks to Amy Zhao for her draft on DHCP Authentication and helping
with laying the ground for this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1994"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.0826"?>
<?rfc include="reference.RFC.1661"?>
<?rfc include="reference.RFC.1990"?>
<?rfc include="reference.RFC.2131"?>
<?rfc include="reference.RFC.2132"?>
<?rfc include="reference.RFC.2364"?>
<?rfc include="reference.RFC.2516"?>
<?rfc include="reference.RFC.2716"?>
<?rfc include="reference.RFC.2865"?>
<?rfc include="reference.RFC.2881"?>
<?rfc include="reference.RFC.3046"?>
<?rfc include="reference.RFC.3118"?>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3396"?>
<?rfc include="reference.RFC.3579"?>
<?rfc include="reference.RFC.3588"?>
<?rfc include="reference.RFC.3748"?>
<?rfc include="reference.RFC.4014"?>
<?rfc include="reference.RFC.4072"?>
<?rfc include="reference.RFC.4284"?>
<?rfc include="reference.I-D.ietf-bfd-base"?>
<reference anchor="TR-059">
<front>
<title>DSL Evolution - Architecture Requirements for the Support of
QoS-Enabled IP Services</title>
<author>
<organization>DSL Forum</organization>
</author>
<date month="September" year="2003" />
</front>
<seriesInfo name="TR" value="059" />
<format target="http://www.dslforum.org/techwork/tr/TR-059.pdf"
type="PDF" />
</reference>
<!--
<reference anchor="TR-101"
target="http://www.dslforum.org/techwork/tr/TR-101.pdf">
-->
<reference anchor="TR-101">
<front>
<title>Migration to Ethernet Based DSL Aggregation</title>
<author>
<organization>DSL Forum</organization>
</author>
<date month="April" year="2006" />
</front>
<seriesInfo name="TR" value="101" />
<format target="http://www.dslforum.org/techwork/tr/TR-101.pdf"
type="PDF" />
</reference>
<reference anchor="WT-146">
<front>
<title>Internet Protocol (IP) Sessions</title>
<author>
<organization>DSL Forum</organization>
</author>
<date month="April" year="2007" />
<abstract>
<t>Numerous members of the service provider community have
recently shown significant interest in migrating from a pure PPP
access environment towards one with IP subscriber sessions for
delivery of all IP services such as voice, video and high speed
Internet over a common data transport protocol. A number of
factors are driving the interest for such a transition. For one,
operators see a potential in simplifying their operational/user
support complexity, as well as harmonizing network element
functionality around the IP protocol. Operators running multiple
access networks also view IP service delivery as the key lowest
common denominator towards delivering common services in a
converged network, where the PPP would be specific only to PSTN
dial and DSL access segments. Given these motivations, the ability
to transition to an IP user service delivery model suggests the
adoption of a subscriber IP session construct in order to allow
the service provider to handle each subscriber according to their
individual service contract. This document provides the
description of the construct and relevant IP node
requirements.</t>
</abstract>
</front>
<seriesInfo name="WT" value="146 (work in progress)" />
<format target="http://www.dslforum.org/techwork/tworkinprogress.shtml"
type="HTML" />
<!--
<annotation/>
-->
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 13:55:07 |