dhc J. Brzozowski
Internet-Draft Comcast Cable Communications
Intended status: Informational T. Lemon
Expires: August 8, 2010 Nominum
G. Hollan
Telus
February 4, 2010
DHCP Authentication Analysis
draft-jjmb-dhc-eap-auth-analysis-02
Abstract
This document analyzes and technically evaluates a proposal by Ric
Pruss, et al., to implement end-user EAP-based authentication as a
part of a DHCP protocol transaction in DSL networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Brzozowski, et al. Expires August 8, 2010 [Page 1]
Internet-Draft DHCP Authentication Analysis February 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message and Option Definition . . . . . . . . . . . . . . . . 3
3.1. Message Type Overloading . . . . . . . . . . . . . . . . . 3
3.2. Differences in Message and Option Names . . . . . . . . . 4
3.3. Message and Option Sizing . . . . . . . . . . . . . . . . 4
3.4. RADIUS Message Requirements . . . . . . . . . . . . . . . 4
4. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . 4
4.1. DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Packet Size . . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Standalone Client Behavior . . . . . . . . . . . . . . 5
4.1.3. Handling of non-EAP responses . . . . . . . . . . . . 5
4.1.4. Protocol State Machine is Only in Client . . . . . . . 5
4.1.5. Transaction IDs . . . . . . . . . . . . . . . . . . . 6
4.1.6. EAP Protocol Direction . . . . . . . . . . . . . . . . 6
4.1.7. Reliable Delivery of EAP messages . . . . . . . . . . 7
4.1.8. Re-Authentication . . . . . . . . . . . . . . . . . . 7
4.1.9. Authorization lifetime versus lease time . . . . . . . 7
4.2. DHCP Servers . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . 8
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Dual-Stack issues . . . . . . . . . . . . . . . . . . . . . . 9
7. Appropriateness . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Brzozowski, et al. Expires August 8, 2010 [Page 2]
Internet-Draft DHCP Authentication Analysis February 2010
1. Introduction
This document provides an independent analysis of the proposal to
support end-user authentication using extension to DHCP. While the
current proposal largley focuses on Broadband Digital Subscriber Line
scenarions the adhoc team that has been assembled will evaulate the
proposal generally from a DHCP point of view. This analysis will
also cite architectural and best practice considerations for the
authors to consider as part of this work.
1.1. 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].
2. Terminology
The following terms and acronyms are used in this document:
o DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131][RFC2132]
o DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" [RFC3315]
o DHCP - DHCPv4 and/or DHCPv6
3. Message and Option Definition
In this section considerations pertaining to how the DHCPEAP messages
have been defined in [I-D.pruss-dhcp-auth-dsl] are discussed.
Recommendations as to how messages may be defined are also documented
in this section.
3.1. Message Type Overloading
[I-D.pruss-dhcp-auth-dsl] defines a DHCP single EAP message to
support end-user DHCP-based authentication. However, the DHC working
group has found that using the same DHCP message type for more than
one leg of a packet exchange creates confusion, and we recommend
instead that a different message type be used for each leg of the
transaction. In this case a four message model may better satisfy
the requirements, similar, for example, to the DISCOVER/OFFER/
REQUEST/ACK cycle in the standard DHCPv4 bootstrapping exchange.
Brzozowski, et al. Expires August 8, 2010 [Page 3]
Internet-Draft DHCP Authentication Analysis February 2010
3.2. Differences in Message and Option Names
[I-D.pruss-dhcp-auth-dsl] mingles DHCPv4 and DHCPv6 message types.
This is not valid. DHCPv4 messages and options must be clearly
defined and referenced to for IPv4. DHCPv6 messages and options must
be defined and referenced for IPv6.
3.3. Message and Option Sizing
[I-D.pruss-dhcp-auth-dsl] introduces a DHCP Capability Vendor-
specific Suboption for DHCPv4 and DHCPv6 which is specified to carry
authentication information. This information is required to support
the desired protocol behavior. However, including this data in a
DHCP greatly increases the size of the DHCP option payload. While
[I-D.pruss-dhcp-auth-dsl] specifies how large options are to be
handled, this large option payload still has the potential to create
problems; there is the potential for this option to squeeze out other
DHCP options required for correct DHCP configuration
Additionally, the authors of [I-D.pruss-dhcp-auth-dsl] should mention
that in practice the Maximum Message Size option is rarely used by
DHCP clients and as such we have no real operational experience that
tells us what percentage of relay agents will fail in the face of
DHCP packets larger than 576 bytes.
3.4. RADIUS Message Requirements
Section 5.1 and 5.2 of [I-D.pruss-dhcp-auth-dsl] mention RADIUS
attributes required to support this behavior. These are not included
as part of [RFC4014]. These messages still need to be specified.
4. Protocol behavior
[I-D.pruss-dhcp-auth-dsl] requires that end-user DHCP-based
authentication must be handled independently in the case where both
IPv4 and IPv6 service are present. [I-D.pruss-dhcp-auth-dsl] is not
clear as to how clients and servers handle conflicts where both IPv4
and IPv6 are used simultaneously and further how conflicts are
resolved when such scenarios arise. See the beginning of section 5
of [I-D.pruss-dhcp-auth-dsl].
4.1. DHCP Clients
4.1.1. Packet Size
Packet size for DHCP clients that support end-user DHCP-based
authentication remains a concern. DHCP clients MUST advertise their
Brzozowski, et al. Expires August 8, 2010 [Page 4]
Internet-Draft DHCP Authentication Analysis February 2010
ability to support larger packet sizes, however, this alone will not
ensure that intermediate elements like DHCP relay agents will support
the same or adversely impact exchanges between DHCP clients and
servers. DHCP clients in this case include but are not limited to
those include with operating systems and home networking equipment.
4.1.2. Standalone Client Behavior
The behavior for home gateway (HG) as defined in
[I-D.pruss-dhcp-auth-dsl] has been specified, however, specification
of standalone client behavior remains absent. In order for this
proposal to be complete it must be specified how standalone client
are to behave to support end-user authentication using DHCP.
4.1.3. Handling of non-EAP responses
Section 5 of [I-D.pruss-dhcp-auth-dsl] also indicates that a client
may receive one or more DHCP OFFER/ADVERTISE messages some of which
may or may not support DHCP EAP authentication. It is unclear and
unspecified how or if the client is to wait for DHCPEAP messages if
it has already received a DHCPOFFER or DHCP Advertise message. An
EAP-capable client could accept a DHCPOFFER or DHCP Advertise message
and consequently miss a subsequent DHCPEAP message, which would
prevent it from authenticating.
This is further complicated in the case where the DHCP client is not
a home gateway, and may in fact be a portable device such as a laptop
computer. When the DHCP/EAP capable client is connected to a
provider network supporting DHCP/EAP, the client may wait for a
DHCPEAP message from the server. When the client is connected to
some other network, where DHCP/EAP is not supported, it may still
wait for such a message. This would create a delay in the
availability of the network for the end user when not connecting to
the provider network.
4.1.4. Protocol State Machine is Only in Client
[I-D.pruss-dhcp-auth-dsl] proposes that if the relay agent or server
decides to do DHCP/EAP, the original DHCPDISCOVER message from the
DHCP client will be cached. Once the EAP authentication has
succeeded, the DHCPDISCOVER will be forwarded to the server or, in
the case where the server does the EAP authentication, the server
will take the cached DHCPDISCOVER and send a DHCPOFFER in response to
it.
However, this proposal ignores the fact that the DHCP client, not the
DHCP server, drives the DHCP protocol. The DHCP client determines
when to send the DHCPDISCOVER, and the DHCP server responds. The
Brzozowski, et al. Expires August 8, 2010 [Page 5]
Internet-Draft DHCP Authentication Analysis February 2010
DHCP client determines when to send the DHCPREQUEST, and the DHCP
server responds. The DHCP client determines when to renew, and so
on.
Hence, we strongly recommend that the proposed protocol be changed so
that, after a successful DHCP/EAP exchange, the DHCP client restarts
its state machine at the INIT state and sends a new DHCPDISCOVER,
with a new transaction ID. This eliminates three problems:
- the need for the DHCP server or relay to cache the DHCPDISCOVER
- the problem of how to retransmit if the DHCP server doesn't send
a response to the DHCPDISCOVER cached and eventually forwarded by
the relay agent
- the problem that the DHCP client state machine would have to
remember the xid in the original DHCPDISCOVER packet, even though
it's gone through several state transitions since the DHCPDISCOVER
was sent.
Needless to say, the same suggestion applies for the DHCPv6 protocol,
although the names of the packets are different and DHCPv6 doesn't
name the client's states.
4.1.5. Transaction IDs
The proposed protocol extension does not document the handling of the
DHCP client's transaction IDs during the processing of EAP-specific
messages. We recommend that each EAP message sourced by the client
have a new transaction ID, which should then be returned in the
response from the server.
4.1.6. EAP Protocol Direction
The proposed protocol extension attempts to replace PPPoE/EAP with a
new protocol based on DHCP. However, the DHCP protocol is client-
initiated, whereas EAP is server-initiated. For example, consider
PPP Extensible Authentication Protocol [RFC3748]. In this document,
the authenticator initiates the packet exchange after the layer two
(PPPoE) connection is established.
The proposal does not explain how this incompatibility is resolved.
Either the proposal needs to turn the DHCP client state machine on
its head, or it needs to turn the EAP state machine on its head. The
document proposes neither solution, so we can't evaluate the impact
the solution to this problem would have on the DHCP protocol.
Brzozowski, et al. Expires August 8, 2010 [Page 6]
Internet-Draft DHCP Authentication Analysis February 2010
4.1.7. Reliable Delivery of EAP messages
The proposal doesn't talk about retransmission for DHCPEAP messages.
This is a particularly important omission because of the reversal of
roles implicit in doing DHCP over EAP, as discussed in the previous
section, "EAP Protocol Direction." Since DHCP is a UDP-based
protocol with no guaranteed delivery, retransmission is not optional,
and the way in which the DHCP client or EAP authenticator does
retransmission must be specified explicitly, or this proposal does
not in any way guarantee interoperability.
4.1.8. Re-Authentication
The proposal doesn't cover re-authentication. Although section 2,
"Problem Statement," mentions user authentication and connection
liveness probing, the actual protocol document never proposes a
method whereby this requirement is satisfied.
We theorize that it might be possible to somehow accomplish this
using DHCPFORCERENEW in DHCPv4 and DHCP Reconfigure in DHCPv6, but
nowhere in the document is this solution discussed. So again, there
is no way to evaluate how the solution to this problem would interact
with DHCP.
4.1.9. Authorization lifetime versus lease time
The underlying authentication protocol may assign a lifetime to the
authorization, after which time the authorization must be renewed.
DHCP clients also have a lease interval, which might be different
than the authorization interval. The proposal should specify that
the lease must expire before the authorization expires, in cases
where the authorization expires. The proposal should also cover re-
authentication, so that a new authorization with a new expiration is
acquired each time the lease is renewed.
4.2. DHCP Servers
In the DHCP protocol, the state machine is in the client, not the
server. The server retains information about the client's IP address
allocation, but from the perspective of the protocol, the DHCP server
only sends messages in response to messages sent by the DHCP client.
So [I-D.pruss-dhcp-auth-dsl] places a new requirement on DHCP servers
that they retain DHCPDISCOVER messages sent by clients during the EAP
authentication process. This problem would be solved by following
the related recommendations in the earlier section on DHCP clients.
Brzozowski, et al. Expires August 8, 2010 [Page 7]
Internet-Draft DHCP Authentication Analysis February 2010
4.3. DHCP Relay Agents
[I-D.pruss-dhcp-auth-dsl] does not say whether or not the relay agent
should append a relay agent information option to EAP-specific
messages. We think that a non-EAP-aware relay agent would have to do
so, but the draft should talk about this issue.
[I-D.pruss-dhcp-auth-dsl] proposes a mode in which the DHCP relay
agent implements the EAP protocol itself, rather than relying on the
DHCP server to do so. In order to do this, the relay agent, which in
the normal DHCP protocol is completely stateless, must now retain
state regarding the progress of the DHCP protocol. There are two
different ways in which this protocol extension adds state to the
relay agent:
- The relay agent must retain the initial DHCPDISCOVER packet sent
by the client.
- Once the EAP authentication has succeeded, the relay agent must
remember that the authentication has succeeded, so that if the
DHCP client must retransmit its DHCPDISCOVER, the relay agent does
not attempt to redo the entire EAP authentication process. This
state must be retained for the entire duration of the DHCP
protocol from that point on, so that the initial four-way
handshake can complete, and so that any subsequent renewals,
rebinds, and INIT-REBOOT renewals can complete. In order to avoid
caching this state forever, the relay agent would have to retain
lease timing information so that it could time out cached
information as the leases associated with that information expire.
For this reason, we strongly recommend that the authors abandon the
idea of implementing this protocol extension in the relay agent.
Also, please note that this is true for the DHCPv6 exchange as well
as the DHCPv4 exchange; we only document the DHCPv4 exchange for
brevity.
5. Compatibility
The compatibility of clients, servers, and relay agents that
implement this behavior with legacy clients, servers, and relay
agents MUST be explicitly documented. The behavior of the remaining
elements that do not support this behavior while others do MUST be
considered, specifically, how will legacy element handle the presence
of the corresponding DHCP options when present. Consider the
following scenarios for example:
Brzozowski, et al. Expires August 8, 2010 [Page 8]
Internet-Draft DHCP Authentication Analysis February 2010
1. DHCP client support for authentication
2. DHCP relay agent support for authentication
3. DHCP server support for authentication
4. DHCP client, server, and relay agent support for authentication
6. Dual-Stack issues
The proposed DHCP extension performs authentication in a way that is
linked with the DHCP transaction. The legacy authentication protocol
may only support a single authentication per connection. In a dual-
stack environment, both the DHCPv4 and DHCPv6 clients might attempt
to authenticate. The underlying authentication protocol might then
succeed for DHCPv4 and fail for DHCPv6, or vice versa.
The proposal should account for this issue, either specifying that in
a dual-stack situation, one or the other DHCP clients should do the
authentication, or specifying that this protocol does not work in a
dual-stack environment, or specifying how the underlying EAP
authentication works in the presence of parallel authentications.
7. Appropriateness
The proposed DHCP extension embeds the network authentication process
into the network configuration process, which, it could be argued,
goes against the recommendation inPrinciples of Internet Host
Configuration [RFC5505], which states:
Network access authentication and authorization is a distinct
problem from Internet host configuration. Therefore, network
access authentication and authorization is best handled
independently of the Internet and higher-layer configuration
mechanisms.
There are two aspects to this objection. The first is that of course
there are reasons why strict adherence to this provision of RFC5505
was not followed. Second, does this provision actually apply?
7.1. Motivation
To address the first point, the motivation stated by the authors for
embedding an authentication protocol into a configuration protocol is
essentially economic: it allows ISPs implementing the protocol to
continue using network infrastructure they have already deployed and
Brzozowski, et al. Expires August 8, 2010 [Page 9]
Internet-Draft DHCP Authentication Analysis February 2010
paid for, while providing a substantial benefit by allowing them to
move away from using PPPoE as, essentially, a gatekeeper protocol and
toward running native (non-tunneled) IP.
A second motivation is that existing protocols for authenticating at
layer two aren't applicable to the DSL environment - 802.1x, for
instance, can't work, because the device doing the authentication has
no connectivity to the node being authenticated until layer three
(IP) configuration has occurred. And yet authentication is required
before decisions can be made as to how to configure the client. The
DHCPv4 and DHCPv6 protocols provide a mechanism for doing the
authentication despite the lack of a layer three configuration.
7.2. Applicability
As to the question of applicability of the statement in question, it
is not really the case that configuration and authentication are
being done by the same protocol. Configuration is being done by
DHCP. Authentication is being done by EAP. True, DHCP is being used
as a transport for the EAP protocol, but it is not the case that DHCP
itself is being used for authentication and authorization.
In addition, existing network access authentication protocols that
work over layer three do use DHCP to configure the node prior to
authentication in cases, such as this, where the authentication agent
is not available on the local link.
Once the node is configured, in order to get new DHCP configuration
information based on the authentication and authorization results, a
second DHCP transaction must be done. In order for this to work,
essentially the same mechanisms being proposed in Authentication
Extensions for the Dynamic Host Configuration Protocol
[I-D.pruss-dhcp-auth-dsl] are needed - the DHCP server or DHCP relay
agent must have access to the results of the authentication. And the
DHCP protocol itself provides no mechanism for reconfiguring
subsequent to a successful layer three authentication. Hence the
difference between such a protocol and the one being proposed is
minor, and largely serves to make the configuration/authentication
process slower and more awkward.
8. Acknowledgements
Thanks to Alper Yegin, Ric Pruss, Glen Zorn, Alan DeKok, Yoshihiro
Ohba, Miles David, Alan Kavanaugh, Steinar Haug and Alfred Hoenes for
the review and feedback.
Brzozowski, et al. Expires August 8, 2010 [Page 10]
Internet-Draft DHCP Authentication Analysis February 2010
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
The current version of [I-D.pruss-dhcp-auth-dsl] indicates that
[RFC3118] likely cannot be seamlessly integrated with existing
RADIUS-based AAA infrastructure used in Broadband DSL environments.
[I-D.pruss-dhcp-auth-dsl] must elaborate on how DHCP EAP can be
secured if not by leveraging [RFC3118]. While the use cases for that
extension are hard to evaluate, so it seems that this draft is
neutral toward other DHCP security mechanisms, with one small caveat:
since it increases the DHCP message size, it is competing for space
in the DHCP packet with other authentication options. However,
existing [RFC3118] authentication schemes use relatively short
signatures and keys, so in practice this is probably not a serious
concern.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.pruss-dhcp-auth-dsl]
Pruss, R. and G. Zorn, "EAP Authentication Extensions for
the Dynamic Host Configuration Protocol for Broadband",
draft-pruss-dhcp-auth-dsl-06 (work in progress),
June 2009.
[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.
[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.
Brzozowski, et al. Expires August 8, 2010 [Page 11]
Internet-Draft DHCP Authentication Analysis February 2010
[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.
[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire,
"Principles of Internet Host Configuration", RFC 5505,
May 2009.
Authors' Addresses
John Jason Brzozowski
Comcast Cable Communications
1360 Goshen Parkway
West Chester, PA 19473
USA
Phone: +1-609-377-6594
Email: john_brzozowski@cable.comcast.com
Ted Lemon
Nominum
USA
Phone:
Email: mellon@nominum.com
Geoffrey Holan
Telus
Canada
Phone:
Email: geoffrey.holan@telus.com
Brzozowski, et al. Expires August 8, 2010 [Page 12]