[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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
                  <draft-mukherjee-dhc-dhcproam-00.txt>

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 <draft-ietf-dhc-aaa-requirements-
      00.txt>, 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 <draft-
      ietf-dhc-enhance-requirements-00.txt>, 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 <draft-ietf-dhc-authentication-14.txt>, July 2000.
   8  S. Das, A. McAuley, A. Baba, Y. Shobatake, "Dynamic Registration
      and Configuration Protocol (DRCP)", Internet Draft <draft-itsumo-
      drcp-01.txt>, July 2000.
   9  R. Troll, _Automatically Choosing an IP Address in an Ad-Hoc IPv4
      Network_, Internet Draft, <draft-ietf-dhc-ipv4-autoconfig-
      05.txt>, 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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/