draft-mukherjee-dhc-dhcproam-00.txt B. Mukherjee Internet Draft B. Gage Y. Liu J. Melzer Nortel Networks October 2000 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 proposes enhancements to DHCP so that it can be used to securely provide dynamic configuration to roaming mobile hosts. The problem has two major aspects: 1) adding extensible, inter-domain, user and network authentication functionality to DHCP and 2) to allow DHCP to function without relying on link layer specific mechanisms. The first feature would allow authenticated and audited visited network usage for roaming users while the second feature would allow DHCP to be used in the new environments like the wireless data networks. The authentication mechanism proposed here interacts with existing public Authentication, Authorization, and Accounting (AAA) mechanisms, thus enabling per customer authentication authorization and accounting across multiple domains. In addition, we propose a mechanism that enables the client to authenticate the DHCP server that has provided it with configuration parameters. We also describe a mechanism that allows DHCP to work independent of link layer broadcasts and addressing. 2. Conventions used in this document Mukherjee, et.al. Expires April 2001 [Page 1] Internet Draft Extensions to DHCP for Roaming Users October, 2000 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 Providing authenticated IP access to a subscriber, across administrative domains, is expected to be a vital part of the functionality of the next generation access networks. In addition users and devices are accessing networks from a variety of environments, from the office desktop to the wireless pagers. As a result, the access networks of the future are expected to operate over a wide variety of link layers. Such access networks are expected to perform authentication, authorization, accounting (AAA) [3] in addition to IP parameters configuration for its subscribers. We believe that DHCP can be used as an initial configuration protocol for the nodes that access such networks. The mechanisms proposed here attempt to address the requirements of such networks in a flexible and extensible manner. In this draft we propose mechanisms that allow DHCP to interface with the existing AAA infrastructure that allows the network to perform the AAA functionality in a flexible manner. Also, in order to use DHCP in new environments the protocol must have mechanisms that allow it to function without relying on layer two (e.g., ethernet) specific features. In this draft we show how using link local IP addresses the DHCP client and relay communicate, removing the reliance on link layer specific mechanisms. In past the DHC working group has also indicated similar concerns and has drafted requirements for AAA to aid roaming nodes using a dynamic address configuration protocol. The WG has also drafted the requirements for extending DHCP to new environments [4]. This draft addresses several of these requirements. 3.1. Motivation It is clear that network access providers would require means to prevent the unauthorized and unbilled use of their network resources. Paying customers would also like to be billed only for their own usage and not those of unauthorized users. Also the new link layers being deployed especially in the wireless networks, make it imperative for DHCP to not rely on any features of the link layer like broadcast. The proposed additions would allow DHCP to be used by commercial access networks as a secure and flexible initial configuration protocol for subscribers, as opposed to its common present use as a means for configuring a pool of trusted clients in a local LAN. 3.2. Overview One of the goals of this work is to propose mechanisms for user authentication to the access network by means of DHCP. To be Mukherjee, et.al. Expires April 2001 [Page 2] Internet Draft Extensions to DHCP for Roaming Users October, 2000 authorized for using the access network, the user must submit credentials to the network 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. In order for DHCP and the proposed mechanisms to be useful for new environments, we also introduce mechanisms that allow DHCP to function without relying on layer two specific features. The authentication messages may also provide a framework for negotiating other parameters, some of which may aid in enhancing security or in providing better performance to the user. The 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 mechanisms that allows the security parameters to be negotiated and established is desirable. The security mechanisms being proposed here can be used to create trust relationships between the network and the client that may be used later 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 proposed additions in DHCP may be of use in new environments. The model of the network that this draft assumes is depicted in the Figure 1 below. This is similar to the model described in the draft on AAA requirements for DHCP [3]. The model assumes that the users may roam and thus authentication is done via a public AAA mechanism. The public AAA infrastructure is assumed to consist of local AAA authorities in each of the access networks. It is assumed that these local AAA servers communicate among each other through a hierarchy of public AAA servers, and there exist security associations between the local AAA server and the DHCP servers. We also assume that 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 in a visited network and then enjoy its use. This model also 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. Furthermore, we do not assume that the client connects to the access network through ethernet. This is because we believe Mukherjee, et.al. Expires April 2001 [Page 3] Internet Draft Extensions to DHCP for Roaming Users October, 2000 that access networks may use different link layers with properties different from ethernet. As a result DHCP mechanisms cannot rely on ethernet broadcasts. 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 perform 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 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 (e.g., UUNET and QUEST) presently use AAA servers which support RADIUS or TACACS+ for customer accounting [6]. In this draft we propose mechanisms that allow DHCP to extensibly interface with this AAA infrastructure thus meeting the requirements set out by the requirements draft [3]. The reason for desiring new features in DHCP, like cross-domain AAA, is that DHCP is being increasingly proposed as a solution for new environments, such as commercial access networks. Some requirements Mukherjee, et.al. Expires April 2001 [Page 4] Internet Draft Extensions to DHCP for Roaming Users October, 2000 for extending DHCP into new environments are listed in [4]. In this draft, DHCP is proposed as a general-purpose framework for performing registration and configuration of nodes in a network, as opposed to being a mechanism for configuring fixed nodes on an internal LAN. 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 confiuration. 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]. We also describe a method by which link local addresses are used for initial DHCP messages so that the protocol does not rely on link layer specific mechanisms of ethernet. We believe that these mechanisms are steps in making DHCP into a flexible intial configuration protocol, propounded by 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 was 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 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 our proposal, the authentication mechanism leverages the AAA infrastructure to not only authenticate the client and the Mukherjee, et.al. Expires April 2001 [Page 5] Internet Draft Extensions to DHCP for Roaming Users October, 2000 server in a symmetric fashion, but also allows 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 an 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. Some of the motivations for DRCP were the same as ours, like the need for a layer two independent protocol. On the other hand unlike DRCP our model does not require 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. Furthermore the request step is skipped. The protocol however does not specify any mechanisms for performing AAA functions or security mechanisms, whereas this is one of our primary motivations. 5.4. Using link local IP addresses DHCP clients can automatically select an IP address in the case that no server responds to its address requests. The draft [9] suggests that this should be used only as an emergency measure. The client is supposed to pick an IP address that is valid only in the local subnet, called LINKLOCAL address. The IANA has specified the address range for IPv4 LINKLOCAL as 169.254/16. The client also needs to check if the address picked is already under use. We use the link local address in a different manner. In order to be independent of the link layer (and its addresses), we do not rely on the use of link layer addresses for even the initial message exchange between the uninitialized DHCP client and the network. This is indeed a requirement in certain scenarios where the existance of a unique link layer adress cannot be guaranteed (e.g., wireless). Also, future link layers may use addressing schemes that may not allow the network to easily map the link layer address to the client. Hence we propose that the DHCP use only IP layer addresses. The client can assign itself a LINKLOCAL IP address and then use that in conjunction with a IP multicast address set aside for DHCP server/relay [10] to communicate with the network, until it has obtained full configuration including an 'global' IP address. In our proposal, as our network model does not assume that all the hosts in the network can be reached by link level broadcasts, we use the relay agent and a randomized address selection algorithm at the client to eliminate the duplicate assignment of the initial LINKLOCAL IP addresses. Mukherjee, et.al. Expires April 2001 [Page 6] Internet Draft Extensions to DHCP for Roaming Users October, 2000 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, which is our prime motivation, 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 in the access network may not be an option. In addition the access networks are expected to interact with each other in order to provide access to roaming users of other access networks. This would mean that for visiting users the access network would need a mechanism to create a security association between the users home domain and itself. On both counts the present message authentication draft falls short of providing a solution. On one hand from the perspective of the subscriber, DHCP should allow access across different service provider domains. On the other hand from the perspective of the service provider there is a need for an authentication and accounting mechanism. We propose that DHCP use the existing AAA mechanisms to authenticate the users potentially across network domains and then initiate accounting using the same. We propose that the DHCP protocol be extended so as to include an authentication phase and add authentication messages to DHCP. In our proposal the DHCP client is 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 is also modified to process the DHCP authentication message and forward the required messages to the AAA components. 6.1. Authentication Messages and Options We propose that two new authentication messages be added to the set of existing DHCP messages: Mukherjee, et.al. Expires April 2001 [Page 7] Internet Draft Extensions to DHCP for Roaming Users October, 2000 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 assined by IANA. The messages are meant to be generic in nature and thus allow the DHCP server and client to establish the required credentials using any protocol they predetermine or negotiate. In fact the authentication phase may be completely skipped to remain backward compatible. But the 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 networks AAA mechanisms. In doing so we are able to leverage the existing AAA infrastructure as well as perform inter domain authentication and accounting. The authentication messages can be sent by either the client or the server, whenever the user or the network wish to establish or (re- establish) a security relationship. We choose new message types for authentication as opposed to piggybacking security information upon other messages, as we believe that the specialized messages would make the process flexible and extensible. Moreover, there are instances like the challenge response protocols, where the present sequence of DHCP messages are unable to fulfill the functionality. For instance future challenges for re-keying in mid-session cannot be fitted in the existing messages without causing the client to restart the configuration procedure. Further if a security protocol that involves negotiation or requires more messages to be exchanged, the present set of messages will no longer be adequate. That is why we propose the new set of messages that allow extensible authentication. The need to be extensible was also propounded in other initial access protocols like PPP, which has an extensible authentication protocol [11]. We also propose options in order to carry authentication information within the messages DHCPAUTHREQ, DHCPAUTHRESP as well other DHCP messages like DHCPREQUEST. The client is expected to present its Network Access Identifier (NAI)[12] and 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 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) [13], digital signature, plain password etc. The current set of option types that may be used are listed below: Mukherjee, et.al. Expires April 2001 [Page 8] Internet Draft Extensions to DHCP for Roaming Users October, 2000 Option # Option Type ---------------------------------------- TBD NAI TBD PAP TBD CHAP TBD Signature Table 1: Proposed options for security 6.2 The DHCP Server The DHCP server model we propose is relatively simple as compared to [7], as it need not manage and process keys or any client specific authentication information by itself. Instead it contacts the local AAA server with the client information, like NAI and password (PAP) and ask the AAA server if it can configure the client or not. For a network that requires a challenge response protocol for authentication the server needs to be able to issue challenge messages with a DHCPAUTHREQ message, receive the DHCPAUTHRES response from the client and forward to the AAA for client authentication. The server also needs to respond to DHCPAUTHREQ messages with a DHCPAUTHRESP message for the client. It may ask the AAA to create a response for the challenge and then send it using the DHCPAUTHRESP message. 6.3. The DHCP Client The DHCP client needs to be modified to incorporate the authentication mechanisms proposed. We add in a state in the clients 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. We choose not to allow the client to send challenges in the other states as it adds unnecessary complexity. The client MUST respond to the DHCPAUTHREQ message by the message DHCPAUTHRESP. Both of these messages carry authentication options as described in 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 on the other hand the client had sent the DHCPAUTHREQ the client MUST leave the AUTHENTICATING state and enter the BOUND sate when a valid DHCPAUTHRES is received. Otherwise 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 Mukherjee, et.al. Expires April 2001 [Page 9] Internet Draft Extensions to DHCP for Roaming Users October, 2000 transitions are the same as described in RFC 2131[14]. 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 proposed client with the new state authenticating as well as the new messages DHCPAUTHREQ and DHCPAUTHRES. Mukherjee, et.al. Expires April 2001 [Page 10] Internet Draft Extensions to DHCP for Roaming Users October, 2000 ------ ------- | | +-------------------------->| |<------------------+ |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. Expires April 2001 [Page 11] Internet Draft Extensions to DHCP for Roaming Users October, 2000 6.4. AAA 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 the DHCP interaction described here. The RADIUS server however needs to be modified in order to support network authentication by the client. The server needs the added functionality to respond to a challenge that may have been sent by a client. Note that the key management and challenge response functions are already available in the server for client authentication. 6.5. Illustrations To see a possible 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 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 intial configuration of a typical host would work when both the client and the network authenticate themselves. 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 Mukherjee, et.al. Expires April 2001 [Page 12] Internet Draft Extensions to DHCP for Roaming Users October, 2000 In the above scenario, the Client starts by sending the NAI in the appropriate predefined option field. It also indicates its preference to perform CHAP authentication by including the CHAP option field. The server can 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, with an Access Request message containing the challenge that was sent to the client, the response received from it. The AAA server may in turn contact the clients 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 The client may also require authorization from the network, and send 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. As an aside note that, the popular AAA protocol, RADIUS, does not respond to challenges at this time. But Mukherjee, et.al. Expires April 2001 [Page 13] Internet Draft Extensions to DHCP for Roaming Users October, 2000 it is expected that means for authenticating the network will be in incorporated the future. 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 above. For the future messages the client and the server may choose a session key and use the message authentication header proposed to the DHC working group [7]. Or the challenge response procedure can be repeated every time the lease is about to expire. For re- authenticating, challenges can be sent using the DHCPAUTHREQ and DHCPAUTHRESP messages at any time and new session keys may be generated. The session key may also be used as the client's ticket to the services of the network. The key may be propagated to the appropriate elements of the network and the client may be required to use it for verifying service requests. For instance, a managed network may require that the client use the key to sign its bandwidth reservation requests, that will be verified at policy decision points that allow disallow the reservation requests. 6.6. Trust relationships and Security Associations Mukherjee, et.al. Expires April 2001 [Page 14] Internet Draft Extensions to DHCP for Roaming Users October, 2000 There are several trust relationships and security associations (SA) that are involved in the process above. 1. DHCP client to DHCP server 2. DHCP server to AAA server 3. AAA server to DHCP server 4. DHCP server to DHCP client 5. DHCP client to AAA server 6. AAA server to DHCP client In our network model we assume that the existence of per-session security associations between the DHCP server and the AAA infrastructure and vice versa (i.e., the SAs 2 and 3 are pre- established). The subscriber and thus the DHCP client is identified by AAA using a predefined key or password(say K1). When the DHCP server sends a challenge to the client, it uses K1 to respond to it. The DHCP server then sends the challenge and response to the AAA server, where the trust relationship 5 can be established. Also using the pre-established SAs 2 and 3 the trust relationship 1 is established (i.e., the DHCP server is told to trust the DHCP client by AAA). Now all that remains is for the network to authenticate itself to the client. The client can send a challenge to the AAA server, with whom it shares the key K1 and use the response to establish the trust relation 6 and by extension the trust relationship 4. In order to avoid going to AAA for every interaction a session key K2 can be generated and be shared between the DHCP client and the server as most future interactions may just require the trust relations 1 and 4. Using the Message authentication proposal of the DHC working group[7] the key K2 can ensure that the renewals are authenticated. 7. Link Local Addresses for Initial Access An issue when trying to extend DHCP into new environments is that it relies on ethernet broadcasts to allow unconfigured nodes to exchange messages with DHCP relay and or server as well as other clients for ARP requests. A DHCP client implementation must either be able to form a link-layer broadcast as in ethernet or send a link-layer unicast packet in the absence of a unicast IP address. In some environments it may be impossible or inadvisable to send link-layer broadcasts. In these cases servers or relays, which receive broadcast packets must be able to unicast responses by direct interaction with the link layer. This makes the DHCP implementation link layer dependent. This may be a problem when different types of link layers with different capabilities are being deployed. We propose that a non-broadcast IP address be used to isolate DHCP from any link-layer specific features of the link layers. Mukherjee, et.al. Expires April 2001 [Page 15] Internet Draft Extensions to DHCP for Roaming Users October, 2000 In view of the new link layer protocols that are being proposed and deployed, it is imperative that DHCP not rely on the link layer being ethernet like. In particular, we believe that broadcasts may not be a feature of all the link layer protocols. It cannot be assumed that all the hosts on the IP layer subnet will be able to receive packets as broadcasts. As a result we need broadcast- independent mechanisms that allow the DHCP client to reach the DHCP server/relay and vice versa. We also need the address conflicts to be resolved without using link layer broadcast. In order to insure reachability of the uninitialized client and the DHCP server/relay, we propose that the DHCP client, upon initialization, assign itself a link local IPv4 address form the range 169.254/16 which is registered with the IANA as the LINKLOCAL net [10] and the DHCP server/relay listen to the IPv4 multicast address 224.0.0.12 assigned to it in the RFC1884 [10]. The client sends out packets intended for the DHCP server/relay to the multicast address 224.0.0.12. and the server/relay replies back to the link local IP address that the client has chosen. In order to ensure that there are no address conflicts, when a DHCPDISCOVER message is received, the DHCP Relay Agent MUST test to see if the source address is already in use. If the network address appears to be in use, the Relay Agent MUST silently discard the DHCPDISCOVER message. If the DHCP client does not receive a response to the DHCPDISCOVER message within its timeout period, it MUST choose another address, and try again. The client MUST keep choosing addresses until it either receives a response to its DHCPDISCOVER message, or it has tried more then the autoconfig-retry count. The autoconfig-retry count is implementation specific, and should be based on the algorithm used for choosing an IP address. This retry count is present to make sure that DHCP Clients auto-configuring on busy auto-configured network segments do not loop infinitely looking for an IP address. After successfully obtaining configuration information, the client changes its IP address to the one given out by the DHCP server to complete the process. 8. Security Considerations Security assumptions for the mechanisms described here are described in section 6.6. 9. References 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. Mukherjee, et.al. Expires April 2001 [Page 16] Internet Draft Extensions to DHCP for Roaming Users October, 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 R. Troll, _Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network_, Internet Draft, , March 2000. 10 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. 11 L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol(EAP)", RFC 2284, March 1998. 12 Aboda, Beadles, "The Network Access Identifier" RFC 2486, January 1999 13 W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. 14 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, 100 Constellation Cr., Napean, ON, K2G 6J8, Canada. Email: biswaroo@nortelnetworks.com Bill Gage Nortel Networks, 100 Constellation Cr., Napean, ON, K2G 6J8, Canada. Email: gageb@ nortelnetworks.com Yajun Liu Nortel Networks, 100 Constellation Cr., Napean, ON, Mukherjee, et.al. Expires April 2001 [Page 17] Internet Draft Extensions to DHCP for Roaming Users October, 2000 K2G 6J8, Canada. Email: yajun@nortelnetworks.com Jordan Melzer Email: jmelzer@usc.edu Mukherjee, et.al. Expires April 2001 [Page 18] Internet Draft Extensions to DHCP for Roaming Users October, 2000 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. Expires April 2001 [Page 19]