draft-ietf-dhc-dhcproam-00.txt B. Mukherjee Internet Draft B. Gage Y. Liu Nortel Networks February 2001 Extensions to DHCP for Roaming Users Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This draft defines enhancements to DHCP so that it can be used by access networks as an initial configuration protocol for nomadic users. The authentication mechanism described here interacts with existing public Authentication, Authorization, and Accounting (AAA) mechanisms, thus enabling per customer authentication and authorization across multiple domains. In addition, we describe a mechanism that enables the client to authenticate the network to prevent attacks on an end host from a bogus network access point. 2. Conventions used in this document 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 [2]. 3. Introduction Mukherjee, et.al. May 2001 [Page 1] Internet Draft Extensions to DHCP for Roaming Users February 2001 Providing authenticated IP access to subscribers across administrative domains is expected to be a vital functionality of next generation access networks. Such access networks are expected to perform authentication, authorization, accounting (AAA) [3] in addition to IP parameter configuration for its subscribers. The mechanisms described here address the requirements for accessing these networks in a flexible and extensible manner using the existing AAA infrastructure to perform the actual authentication. Similar motivations were expressed in proposing requirements for extending DHCP to new environments [4]. We expect that the proposed mechanisms will allow DHCP to be used as a secure yet easy to administer initial configuration protocol in commercial access networks as opposed to its present usage as means of configuring a pool of trusted hosts in a LAN. 3.2. Overview This document defines mechanisms for authentication in access networks by means of DHCP. In order to be authorized for using the access network, the user must submit credentials via DHCP authentication messages. In response, the access network may indicate that a user has been authorized by providing configuration parameters to the user's mobile host. The user may also verify the access network's credentials as a part of the process. The authentication messages also provide a framework for negotiating other parameters, some of which may aid in enhancing the security of the system. Any proposed security mechanism should allow flexible authentication between the network and its subscribers with scope for negotiation about the mechanisms to be used and the type of ciphers (e.g., ssl handshakes [5]). This is because the networks and their users may support only a few of the possible wide range of security mechanisms available. This may be due to internal constraints of the hosts (e.g., CPU cycles may be a bottleneck in case of a mobile user) or the security level the hosts desire (e.g., the network may only allow users that perform per message authentication). Furthermore no assumptions can be made about the local security requirements of visited domains. Thus a flexible mechanism that allows the security parameters to be negotiated and established is desirable. The security mechanisms defined here can be used to create trust relationships between the network and the client that may be used then for accountable usage of the network resources. 4. Network Model Throughout this document we use the example of an access network in order to demonstrate how the authentication additions in DHCP may be of use in new environments. The model of the network used by this draft is depicted in the Figure 1 below. This is similar to the model described in the draft on AAA requirements for DHCP [3]. The Mukherjee, et.al. May 2001 [Page 2] Internet Draft Extensions to DHCP for Roaming Users February 2001 model assumes that the users may roam and thus their initial interaction with the accessed network is overseen by a public AAA mechanism. The public AAA infrastructure consists of local AAA authorities in each of the access networks. These local AAA servers communicate among each other through a hierarchy of public AAA servers, and security associations exist between the local AAA server and the DHCP servers. The public AAA servers have inter domain security associations through the public AAA servers that allow them to authenticate users from visited domains. Thus upon presenting the right information a user can authenticate himself to a visited network, obtain the right levels of authorization and at the same time be accountable for the use of the network. This model allows the network access provider to leverage the existing AAA mechanisms to perform user authentication and accounting in a scalable manner across domains instead of using localized mechanisms. Subscriber Visited Domain Home Domain +-------------+ +-------------+ | +------+ | | +------+ | | | AAAL | | | | AAAL | | | | +---+--------+--+ | | | +---+--+ | | +------+ | | | | | | | | | +-------------+ | | | | | | +-------+ +------+ +--+---+ | |DHCP | |DHCP | |DHCP | | |Client |---+Relay +-+Server| | +-------+ +------+ +------+ | | | AAAL = local authority +-------------+ Figure 1: DHCP's interaction with AAA 5. Related Work The DHCP working group of IETF has in the past expressed the need for DHCP to support AAA functions [3] and be extensible to different environments than ethernet LANs [4]. These are the principal motivations behind our work. 5.1 Requirements for using DHCP in new environments Mukherjee, et.al. May 2001 [Page 3] Internet Draft Extensions to DHCP for Roaming Users February 2001 The draft [3] had proposed that DHCP use the public AAA server infrastructure to perform AAA for roaming nodes and had set out the requirements for the same. Leveraging the AAA infrastructure provides a network service provider with a scalable way of ensuring access security because it does not require every DHCP server to have a pre-established security association with every DHCP client it may ever talk to. Using the public AAA infrastructure, the DHCP servers will be able to provide access to nodes from visited domains and bill them through their local service providers. Most major ISPs presently use AAA servers which support RADIUS or TACACS+ for customer accounting [6]. In this draft we describe mechanisms that allow DHCP to extensibly interface with this AAA infrastructure thus meeting the requirements set out by the requirements draft [3]. 5.2 Mobile IP and PPP There are other commonly used protocols like PPP and mobile IP, which are used for related functions. We contend that none of the above protocols are as suited for initial registration and configuration as DHCP. For instance, PPP's registration model assumes a point-to-point connection and is requires explicit link configuration before entering into IP authentication and configuration. This leads to considerable delay and overhead in providing access to the mobile host. Moreover when the host roams the physical layer parameters may change and may cause PPP to restart configuration to reinitialize its link layer. Mobile IP based registration depends on the availability of the 'home-agent' and is tied in to that particular mobility solution. New generations of wireless networks may use and deploy several other types of mobility solutions. Thus there exists the need for a general-purpose protocol for registration and configuration that is not tied in to other functions or environments. DHCP is a natural choice because it exclusively deals with registration and configuration of nodes, independent of other functions being handled in a particular scenario. The draft [4] argues in favor of using DHCP as a general- purpose registration and configuration mechanism. In our proposal we address several of the requirements listed in this draft[4]. 5.2. DHCP message authentication option. The DHC WG has produced a draft that describes an authentication method for DHCP messages [7]. This involves a replay detection method as well as a keyed hash that allows the receiver of the message to authenticate the source. The mechanism relies on a shared secret between the two negotiating authorities. For the case of servers providing service to local clients, the above mechanism may be sufficient. But in the more general case of the clients roaming across domains it is not possible to create all the possible key associations before hand. Possible solutions to this problem were discussed in the DHC WG meeting on June 1998. It may be possible to use the public key infrastructure to authenticate the client and the server and then use Diffie-Hellman to generate a shared secret that Mukherjee, et.al. May 2001 [Page 4] Internet Draft Extensions to DHCP for Roaming Users February 2001 can then be used to authenticate messages. But a potential problem is that an uninitialized client may not be able to contact a trusted PKI node, resulting in an asymmetrical security relationship against the client. For instance, the server's certificate may have been revoked by the PKI authority and the client has no means of finding that out. In this document, the authentication mechanism leverages the AAA infrastructure to not only authenticate the client and the server in a symmetric fashion, but also to allow the network to initiate the AAA functions at the same time. In addition, the extra set of messages and the state allow the use of additional security mechanisms, like re-keying, that cannot be completed by piggybacking on the present set of DHCP messages. Another proposal was to create a IPSEC security association between the client and the server. Setting up a valid security association with an uninitialized client may not be possible without a valid IP address and a configured stack. 5.3. Dynamic Registration and Configuration Protocol Another protocol, called Dynamic Registration and Configuration Protocol (DRCP)[8], was proposed in order to address the need for new features in a registration and configuration framework like DHCP. However DRCP requires every client to be a router. The DRCP protocol allows the servers to send advertisement messages that allow the clients to send discover messages to the servers using unicast. The protocol however does not specify any mechanisms for performing AAA functions or security mechanisms. 6. DHCP with Extensible Authentication Adding authentication to DHCP allows the client and the server to establish mutual trust before configuration is effected. From the perspective of an access network, authentication mechanisms in DHCP allow easy configuration of subscriber devices as well as protection against certain theft of service attacks. A simple approach to prevent unauthorized access is that the configuration of the mobile host be completed only after the user is authenticated. The underlying assumption being that the configuration step is the one that allows a client to act as a fully functional host and access the network and its resources, and if this step fails to complete the mobile will be incapable of using the network. The threat scenario that this addresses is when a user attempts to access the IP services of the network without presenting valid credentials (e.g., user-id or password). However the authentication mechanism used by the access networks must be scalable as each of the access networks are expected to be extensive. Thus pre-establishing security association between every client and the DHCP servers[9] in the access network may not be a viable option. In addition, the home and visited systems are expected to interact with each other in order to provide access to roaming users of other access networks. This would mean that for Mukherjee, et.al. May 2001 [Page 5] Internet Draft Extensions to DHCP for Roaming Users February 2001 visiting users the access network would need a mechanism to create a security association between the users home domain and itself. From the perspective of the subscriber, DHCP should allow access across different service provider domains. From the perspective of the service provider there is a need for an authentication mechanism in order to provide service to subscribers roaming from other networks. This document describes an optional extension to the DHCP protocol to include an authentication phase and to add authentication messages to DHCP. To support this option, the DHCP client must be modified to include a new state and to send new messages and options for authentication. The DHCP relay agent may remain the same, and does not need to be altered for the authentication phase. The DHCP server must also be modified to process the DHCP authentication messages and to forward the required messages to the AAA components. 6.1. Authentication Messages and Options This option adds two new authentication messages to the set of existing DHCP messages: DHCPAUTHREQ Request for authentication information (e.g. request for challenge response). DHCPAUTHRESP Response to a DHCPAUTHREQ The value of message type for new messages is left as TBD until assigned by IANA. The messages are generic in nature and thus allow the DHCP server and client to establish the required credentials using any authentication protocol they predetermine or negotiate. The authentication phase may be completely skipped to remain backward compatible but the DHCP server may enforce a policy that makes authentication mandatory for certain (groups of) mobiles. The new messages function as means of transporting authentication information to and from the network's AAA mechanisms. In doing so we are able to leverage the existing AAA infrastructure to perform inter-domain authentication and authorization. This document defines new message types for authentication, as opposed to piggybacking security information upon existing messages, in order to make the process flexible and extensible. For example, there are instances like the challenge-response protocols where the present sequences of DHCP messages are unable to fulfill the functionality. In addition challenges for re-keying in mid-session cannot be fitted in the existing messages without causing the client to restart the configuration procedure. The separate messages also allow the authentication protocol to be symmetrical, allowing the server to authenticate the client and the client, if necessary, to authenticate the server. The need to be extensible was also Mukherjee, et.al. May 2001 [Page 6] Internet Draft Extensions to DHCP for Roaming Users February 2001 propounded in other initial access protocols like PPP, which itself has an extensible authentication protocol [10]. Several new options are defined to carry authentication information within the DHCPAUTHREQ and DHCPAUTHRESP messages as well as in other DHCP messages like DHCPREQUEST and DHCPACK. The client uses the DHCPREQUEST message to present its Network Access Identifier (NAI)[11] and to request the use of an (or possibly a set of) authentication mechanism by setting the appropriate option fields. The server can then query its local AAA mechanism about the security parameters supported for the given NAI. The DHCP server then can use the authentication request message (DHCPATHREQ) to ask the client to present it with authentication information that will be relayed on to the AAA mechanism. The option fields are thus used to indicate the choice when negotiating and then to carry actual data during the security exchange. The authentication mechanisms may be a challenge response handshake protocol (CHAP) [12], digital signature, plain password etc. The current set of option types that may be used are listed below: Option # Option Type ---------------------------------------- TBD NAI TBD PAP TBD CHAP TBD Signature Table 1: Authentication Options 6.2 The DHCP Server The DHCP server model is relatively simple as compared to [7], as it need not manage and process keys or any client specific authentication information by itself. The DHCP server receives the user identification (e.g. NAI) from the client in a DHCPREQUEST; if the client is supporting a password protocol (e.g. PAP), the DHCPREQUEST may also include the password. The DHCP server then contacts the local AAA server (e.g. using RADIUS) with the DHCP client information and asks the AAA server if it can configure the client. For a network that uses a challenge response protocol for authentication, the server issues the challenge with a DHCPAUTHREQ message, receives the challenge response from the client through a DHCPAUTHRESP message and forwards the response to the AAA server for client authentication. If the client chooses to authenticate the network, the DHCP server also needs to respond to DHCPAUTHREQ messages with a DHCPAUTHRESP message for the client. If a challenge-response protocol is used by the client for network authentication, the DHCP server must ask the AAA server to create a response for the challenge. Extensions to existing AAA protocols to support this function are beyond the scope of this document. Mukherjee, et.al. May 2001 [Page 7] Internet Draft Extensions to DHCP for Roaming Users February 2001 6.3. The DHCP Client The DHCP client needs to be modified to incorporate the optional authentication mechanisms. First, it requires a new state in the client's state machine called AUTHENTICATING. This state is entered upon the receipt of a DHCPAUTHREQ message or when the client sends out a DHCPAUTHREQ message. The client MUST respond to a DHCPAUTHREQ message received when it is in the states REBOOTING, REQUESTING, RENEWING, REBINDING and AUTHENTICATING. The client MAY send DHCPAUTHREQ when it is in the BOUND or AUTHENTICATING state. The client MUST respond to the DHCPAUTHREQ message with the message DHCPAUTHRESP. Both of these messages carry authentication options as described above. If the server had issued the challenge, the client MUST depart from the AUTHENTICATING state upon the receipt of a DHCPACK or a DHCPNACK message. The client MUST return to the bound state if the server responds with a DHCPACK but if the message received is DHCPNAK it MUST go back to the INIT state. If the client had sent the DHCPAUTHREQ, the client MUST leave the AUTHENTICATING state and enter the BOUND state when a valid DHCPAUTHRES is received. If a valid DHCPAUTHRESP is not received, the client MUST enter the REBIND state and obtain new configuration parameters. The lease timers MUST be set as per the security requirements such that the server and the client cannot delay the response to the AUTHREQ messages indefinitely. Upon the expiry of the T1 and T2 timers the authenticating client MUST enter the REBINDING and RENEWING state respectively. The remaining state transitions are the same as described in RFC 2131[13]. The DHCP client also needs to be augmented with an authentication module that can manage keys, respond to challenges or encrypt messages. The specific functions of the authentication module is implementation dependent. The following is the state diagram for the client with the new state AUTHENTICATING as well as the new messages DHCPAUTHREQ and DHCPAUTHRES. Mukherjee, et.al. May 2001 [Page 8] Internet Draft Extensions to DHCP for Roaming Users February 2001 ------ ------- | | +-------------------------->| |<------------------+ |INIT- | | +------------------>| INIT | | |REBOOT|DHCPNAK/ | +---------->| |<---+ | | |Restart | | ------- | | ------ | DHCPNAK/ | | | | |Discard offer | -/Send DHCPDISCOVER | -/Send DHCPREQUEST | | | | | | DHCPACK v | | ----------- | (not accept.)/ ----------- | | | | |Send DHCPDECLINE | | | | REBOOTING | | | | SELECTING |<----+ | | | | / | | |DHCPOFFER/ | ----------- | / ----------- | |Collect | | | / | | | replies | DHCPACK/ | / +----------------+ +-------+ | Record lease, set| | v Select offer/ | timers T1, T2 ------------ send DHCPREQUEST | | | +----->| | DHCPNAK, Lease expired/ | | | | REQUESTING | Halt network | DHCPOFFER/ | | | | Discard /------------ | | | | / | | ----------- | | +----/---+ DHCPACK/ | | | | / Record lease, set -----| REBINDING | | | DHCPAUTHREQ timers T1, T2 / | | | | / | DHCPACK/ ----------- | | / v Record lease, set ^ | | +---/------------> ------- /timers T1,T2 | DHCPAUTHREQ | | +----->| |<---+ | | | | | BOUND |<---+ | | DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ DHCPNAK/Discard -> ------- | Broadcast Halt network | / | | | DHCPREQUEST | | +-------+ | DHCPACK/ | | | | T1 expires/ Record lease, set | | | DHCP | Send DHCPREQUEST timers T1, T2 | | | AUTHREQ| to leasing server | | | | -/Send | | ---------- | | | DHCP | / | | |-----------+ | | AUTHRES| DHCPACK +->| RENEWING | | +---+ | / | |-------------------------+ | | v / /---------- | | ------- DHCPAUTHREQ / | | +->| |<-------------+----------------------------+ | |AUTHENTICATING | | |----------------DHCPNACK-----------------------------+ ------- Figure 2: State-transition diagram for DHCP clients Mukherjee, et.al. May 2001 [Page 9] Internet Draft Extensions to DHCP for Roaming Users February 2001 6.4. Interworking with AAA Servers The AAA mechanisms described here are similar to the ones already deployed and used by ISPs to serve PPP users. A AAA protocol like RADIUS can be employed with no modification to support client authentication by the network. The RADIUS protocol however needs to be modified in order to support network authentication by the client. These modifications are beyond the scope of this document. 6.5. Illustrations To see the use of the authentication mechanisms described here, consider the case of a subscriber connecting to an access network and requesting configuration using DHCP. Figures below show the message flow between DHCP components of a network and their interaction with the AAA components. In the first case the network authenticates the client and in the second case the client authenticates the network. The last illustration shows how the initial configuration of a typical host would work when both the client and the network are being authenticated. DHCP Client DHCP Server AAA v v v | | | .. .. .. |\_____________ | | | DHCPREQUEST \| | | (nai+chap) | | | _____________/| | |/DHCPAUTHREQ | | | (c1) | | |\_____________ | | | DHCPAUTHRES \| | | (r1) | | | |\______________ | | | AccessRequest \| | | (c1 + r1) | | | ______________/| | |/ AccessResponse| | | (accept) | | _____________/| | |/ DHCPACK | | | | | | | | | Initialization complete | v v v Figure 3: Authentication of the client In Figure 3, the Client starts by sending the NAI in the appropriate option field. It also indicates its preference to perform CHAP authentication by including the CHAP option field. The server can Mukherjee, et.al. May 2001 [Page 10] Internet Draft Extensions to DHCP for Roaming Users February 2001 check that it does indeed support the requested authentication method and thus sends an authentication request message with the challenge in the CHAP option. The client can now use a key shared with its home AAA authority to respond to the challenge. Upon receiving the response, the DHCP server can then contact the local AAA server using, for example, a RADIUS Access Request message containing the challenge that was sent to the client and the response received from it. The AAA server may in turn contact the client's local AAA server. The AAA authority can then verify if the client's response to the challenge was correct using the shared key. The DHCP server, upon receiving the access response, will send a DHCPACK if the client authentication succeeded or DHCPNAK otherwise. Finally the DHCP client can verify and accept the parameters sent to it in the DHCPACK message. DHCP Client DHCP Server AAA v v v | | | .. .. .. | | | |\_____________ | | | DHCPAUTHREQ \| | | (nai+c2) | | | |\______________ | | | AuthRequest \| | | (c2) | | | ______________/| | |/ AuthResponse | | | (r2) | | _____________/| | |/ DHCPAUTHRES | | | (r2) | | | | | | Network authentication complete| v v v Figure 4: Authentication of the network As shown in Figure 4, the client may also require authentication of the network and sends its own challenge to the network in a DHCPAUTHREQ message. The DHCP server may forward that request to the AAA server who will then use the key it shares with the client to respond. The Client upon confirming that the response was correct will reenter bound state and resume normal operation. Otherwise, if the response to the challenge was incorrect, it may reject the parameters it was given and restart configuration. Mukherjee, et.al. May 2001 [Page 11] Internet Draft Extensions to DHCP for Roaming Users February 2001 DHCP Client DHCP Server AAA v v v | | | .. .. .. | | | |\_____________ | | | DHCPREQUEST \| | | (nai+chap) | | | _____________/| | |/DHCPAUTHREQ | | | (c1) | | |\_____________ | | | DHCPAUTHRES \| | | (r1+c2) | | | |\______________ | | | AccessRequest \| | | (c1+r1+c2) | | | ______________/| | |/ AccessResponse| | | (accept+r2) | | _____________/| | |/ DHCPACK | | | (r2) | | | | | | Initialization complete | v v v Figure 5: Authentication of the client and the network During initial configuration when both sides may want to establish trust the two steps above may be combined as shown in Figure 5. In this case, the network's challenge is contained in its DHCPAUTHREQ message and the client's response is contained in its DHCPAUTRES message. The client's challenge is also contained in its DHCPAUTHRES message and the network's response to the challenge is contained in its DHCPACK message. For re-authenticating, challenges can be sent using the DHCPAUTHREQ and DHCPAUTHRESP messages at any time without the need for reconfiguration or rebinding. 7. Security Considerations The purpose of this document is to describe a mechanism for authenticating DHCP clients and servers. It does not cover other possible security attacks such as IP spoofing. 8. References Mukherjee, et.al. May 2001 [Page 12] Internet Draft Extensions to DHCP for Roaming Users February 2001 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 S. Das, A. McAuley, A. Baba, Y. Shobatake, _Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP_, Internet Draft , March 2000. 4 S. Das, A. McAuley, A. Baba, Y. Shobatake, _Requirements for Extending DHCP into New Environments_, Internet Draft , March 2000. 5 K. Hickman, "The SSL protocol", Netscape Communication Corp., February 1995 6 C. Munroe, "http://www.uu.net/press_center/hot_tech_topics/vpn/vpn- whitepaper.pdf", White Paper, May 2000. 7 R. Dorms, W. Arbaugh, "Authentication for DHCP Message", Internet Draft , July 2000. 8 S. Das, A. McAuley, A. Baba, Y. Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)", Internet Draft , July 2000. 9 B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC Load Balancing Algorithm", Internet Draft, . 11 L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol(EAP)", RFC 2284, March 1998. 11 Aboda, Beadles, "The Network Access Identifier" RFC 2486, January 1999 12 W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. 13 R. Dorms, "The Dynamic Host Control Protocol", RFC 2131, March 1997 10. Acknowledgments We Acknowledge the help of Kris Ng and all the members of the Advanced Wireless research group at Nortel Networks. 11. Author's Addresses Biswaroop Mukherjee Nortel Networks, Ottawa, ON, Canada. Email: biswaroo@nortelnetworks.com Bill Gage Nortel Networks, Ottawa, ON, Canada. Email: gageb@ nortelnetworks.com Yajun Liu Mukherjee, et.al. May 2001 [Page 13] Internet Draft Extensions to DHCP for Roaming Users February 2001 Nortel Networks, Ottawa, ON, Canada. Email: yajun@nortelnetworks.com Mukherjee, et.al. May 2001 [Page 14] Internet Draft Extensions to DHCP for Roaming Users February 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Mukherjee, et.al. May 2001 [Page 15]