dhc J. Brzozowski Internet-Draft Comcast Cable Communications Intended status: Informational T. Lemon Expires: May 23, 2010 Nominum G. Hollan Telus November 19, 2009 DHCP Authentication Analysis draft-jjmb-dhc-eap-auth-analysis-01 Abstract This document analyzes and technically evaluate the techniques proposed to support end-user authentication using extensions to DHCP. 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 May 23, 2010. Copyright Notice Copyright (c) 2009 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 (http://trustee.ietf.org/license-info) in effect on the date of Brzozowski, et al. Expires May 23, 2010 [Page 1] Internet-Draft DHCP Authentication Analysis November 2009 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.2. DHCP Servers . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . 7 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Brzozowski, et al. Expires May 23, 2010 [Page 2] Internet-Draft DHCP Authentication Analysis November 2009 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] 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 May 23, 2010 [Page 3] Internet-Draft DHCP Authentication Analysis November 2009 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 May 23, 2010 [Page 4] Internet-Draft DHCP Authentication Analysis November 2009 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 May 23, 2010 [Page 5] Internet-Draft DHCP Authentication Analysis November 2009 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 [RFC2284]. 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 May 23, 2010 [Page 6] Internet-Draft DHCP Authentication Analysis November 2009 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.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. 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 Brzozowski, et al. Expires May 23, 2010 [Page 7] Internet-Draft DHCP Authentication Analysis November 2009 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: 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 Brzozowski, et al. Expires May 23, 2010 [Page 8] Internet-Draft DHCP Authentication Analysis November 2009 6. Acknowledgements Thanks to Alper Yegin, Ric Pruss, Glen Zorn, and Alan DeKok for the review and feedback. 7. IANA Considerations This memo includes no request to IANA. 8. 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [I-D.pruss-dhcp-auth-dsl] Pruss, R., Zorn, G., Maglione, R., and Y. Li, "Authentication Extensions for the Dynamic Host Configuration Protocol", May 2008. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", Brzozowski, et al. Expires May 23, 2010 [Page 9] Internet-Draft DHCP Authentication Analysis November 2009 March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", March 1997. [RFC2284] Blunk, L. and J. Droms, "DHCP Options and BOOTP Vendor Extensions", March 1998. [RFC3118] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4014] Droms, R., "Dynamic Host Configuration Protocol", March 1997. 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 Brzozowski, et al. Expires May 23, 2010 [Page 10] Internet-Draft DHCP Authentication Analysis November 2009 Geoffrey Holan Telus Canada Phone: Email: geoffrey.holan@telus.com Brzozowski, et al. Expires May 23, 2010 [Page 11]