DHCP Authentication Analysis
draft-jjmb-dhc-eap-auth-analysis-00

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 15, 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 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
    1.1.  Requirements Language
2.  Terminology
3.  Message and Option Definition
    3.1.  Message Type Overloading
    3.2.  Differences in Message and Option Names
    3.3.  Message and Option Sizing
    3.4.  RADIUS Message Requirements
4.  Protocol behavior
    4.1.  DHCP Clients
        4.1.1.  Packet Size
        4.1.2.  Standalone Client Behavior
        4.1.3.  Handling of non-EAP responses
        4.1.4.  Protocol State Machine is Only in Client
        4.1.5.  Transaction IDs
        4.1.6.  Retransmission
    4.2.  DHCP Servers
    4.3.  DHCP Relay Agents
5.  Compatibility
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Terminology

The following terms and acronyms are used in this document:

• DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.)
• DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.)
• 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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.

3.2.  Differences in Message and Option Names

[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.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) mention RADIUS attributes required to support this behavior. These are not included as part of [RFC4014] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.). These messages still need to be specified.

4.  Protocol behavior

[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.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.).

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 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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 DHCP OFFER/ADVERTISE messages that support EAP. An EAP-capable client could accept a DHCP OFFER/ADVERTISEMENT message where no support for EAP is in present but subsequent DHCP OFFER/ADVERTISEMENT messages do.

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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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 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.  Retransmission

The proposed protocol extension does not talk about retransmission in cases where no response is received during the EAP portion of the protocol. It must document this, or refer to relevent text in the DHCPv4 and DHCPv6 protocol specs.

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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) 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:

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.  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] (Pruss, R., Zorn, G., Maglione, R., and Y. Li, “Authentication Extensions for the Dynamic Host Configuration Protocol,” May 2008.) indicates that [RFC3118] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) likely cannot be seamlessly integrated with existing RADIUS-based AAA infrastructure used in Broadband DSL environments. [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.) must elaborate on how DHCP EAP can be secured if not by leveraging [RFC3118] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.). 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] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) authentication schemes use relatively short signatures and keys, so in practice this is probably not a serious concern.

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses