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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Laboratories, Inc.
Title: draft-calhoun-diameter-mobileip-07.txt         Charles E. Perkins
Date: April 2000                                   Nokia Research Center



                     DIAMETER Mobile IP Extensions



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:

      http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:

      http://www.ietf.org/shadow.html.

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@diameter.org mailing list.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.












Calhoun, Perkins          expires October 2000                  [Page 1]


INTERNET DRAFT                                                April 2000


Abstract

   This document specifies an extension to the DIAMETER base protocol
   that allows a DIAMETER server to authenticate, authorize and collect
   accounting information for services rendered to a mobile node.
   Combined with the Inter-Domain capability of the base protocol, this
   extension allows mobile nodes to receive service from foreign service
   providers. The DIAMETER Accounting extension will be used by the
   Foreign and Home agents to transfer usage information to the DIAMETER
   servers.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Inter-Domain Mobile IP
            1.3  Key Distribution Center
            1.4  Allocation of Home Agent in Foreign Network
            1.5  DIAMETER Session Termination
      2.0  Command-Code AVP Values
            2.1  AA-Mobile-Node-Request (AMR) Command
            2.2  AA-Mobile-Node-Answer (AMA) Command
            2.3  Home-Agent-MIP-Request (HAR) Command
            2.4  Home-Agent-MIP-Answer (HAA) Command
      3.0  Result-Code AVP Values
      4.0  DIAMETER AVPs
            4.1  MIP-Registration-Request AVP
            4.2  MIP-Registration-Reply AVP
            4.3  MN-FA-Challenge-Length AVP
            4.4  MN-FA-Response AVP
            4.5  Mobile-Node-Address AVP
            4.6  Home-Agent-Address AVP
            4.7  Previous-FA-NAI AVP
            4.8  Foreign-Home-Agent-Available AVP
            4.9  MN-AAA-SPI AVP
      5.0  Key Distribution Center (KDC) AVPs
            5.1  Mobile Node Session Key AVPs
            5.2  Mobility Agent Session Key AVPs
            5.3  FA-MN-Preferred-SPI AVP
            5.4  FA-HA-Preferred-SPI AVP
      6.0  Interactions with Resource Management
      7.0  Acknowledgements
      8.0  IANA Considerations
      9.0  Security Considerations
      10.0 References
      11.0 Authors' Addresses
      12.0 Full Copyright Statement



Calhoun, Perkins          expires October 2000                  [Page 2]


INTERNET DRAFT                                                April 2000


1.0  Introduction

   The Mobile IP [4] protocol defines a method that allows a Mobile Node
   to change its point of attachment to the Internet without service
   disruption.  The Mobile IP protocol, as defined in [4], assumes that
   mobility is performed in a single administrative domain, and
   therefore does not specify how usage can be accounted for, which
   limits the applicability of Mobile IP in a commercial deployment.
   Further, the protocol requires that a mobile node has a static home
   agent, and home address, which is not desirable in a commercial
   network.

   This document specifies an extension to the DIAMETER base protocol
   [1] that allows a DIAMETER server to authenticate, authorize and
   collect accounting information for services rendered to a mobile
   node. Combined with the Inter-Domain capability of the base protocol,
   this extension allows mobile nodes to receive service from foreign
   service providers. The DIAMETER Accounting extension [12] will be
   used by the Foreign and Home agents to transfer usage information to
   the DIAMETER servers.

   The Mobile IP protocol [4] specifies a security model that requires
   that mobile nodes and home agents share a pre-existing security
   association, which leads to scaling and configuration issues. This
   specification defines an optional DIAMETER function that allows the
   mobile's home AAA server to act as a Key Distribution Center (KDC),
   where dynamic session keys are created and distributed to the
   mobility entities for the purposes of securing Mobile IP Registration
   messages.

   As with the DIAMETER base protocol, the Mobile IP extension requires
   the presence of users' identities in a format consistent with the
   Network Access Identifier (NAI) specification [6], which is used for
   DIAMETER message routing purposes. This requires mobile nodes to
   include their identity in Registration messages, as defined in [8].
   The use of the NAI is consistent with the current roaming model, as
   defined by the ROAMOPS Working Group [7].

   This specification defines the DIAMETER Mobile-IP Extension, and
   addresses all of the requirements specified in [3, 16]. This section
   will provides some examples and message flows of the Mobile IP and
   DIAMETER messages that occur when a Mobile Node requests service in a
   foreign network.

   The Extension number for this draft is four (4). DIAMETER nodes
   conforming to this specification MUST include an Extension-Id AVP
   with a value of four in the Device-Reboot-Ind Command [1].




Calhoun, Perkins          expires October 2000                  [Page 3]


INTERNET DRAFT                                                April 2000


1.1  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [11].


1.2  Inter-Domain Mobile IP

   When a Mobile Node node requests service by issuing a Registration
   Request to the foreign agent (FA), the FA creates the AA-Mobile-
   Node-Request (AMR) message, which includes the AVPs defined in
   section 2.1. The Home Address, Home Agent, Mobile Node NAI and other
   important fields are extracted from the registration messages and
   included as DIAMETER AVPs. The request is then forwarded to the FA's
   local DIAMETER server, known as the AAA-Foreign, or AAAF.

                            ISP                   Home Network
                        +--------+                 +--------+
                        |abc.com |      AMR/A      |xyz.com |
                        |  AAAF  |<--------------->|  AAAH  |
                     +->| server |  server-server  | server |
                     |  +--------+  communication  +--------+
                     |         ^                     ^
                     | AMR/AMA | client-server       | HAR/A
                     |         | communication       |
                     v         v                     v
             +---------+      +---------+          +---------+
             | Foreign |      | Foreign |          |  Home   |
             |  Agent  |      |  Agent  |          |  Agent  |
             +---------+      +---------+          +---------+
                               ^
                               | Mobile IP
                               |
                               v
                              +--------+
                              | Mobile |
                              | Node   | mn@xyz.com
                              +--------+

                      Figure 1: Inter-Domain Mobility

   Upon receiving the AMR, the AAAF follows the procedures outlined in
   [1] to determine whether the AMR should be processed locally, or if
   it should be forwarded to another DIAMETER Server, known as the AAA-
   Home, or AAAH. Figure 1 describes an example of a mobile node
   (mn@xyz.com) requests service from a foreign provider (abc.com). The
   request received by the AAAF is forwarded to abc.com's AAAH server.



Calhoun, Perkins          expires October 2000                  [Page 4]


INTERNET DRAFT                                                April 2000


   Figure 2 provides an example of the message flows involved when the
   Foreign Agent invokes the AAA infrastructure to request that a mobile
   node be authenticated and authorized. Note that it is not required
   that the Foreign Agent invoke the AAA every time a Registration
   Request is received by the mobile, but rather when the prior
   authorization from the AAAH expires. The expiration of the
   authorization (and session keys, if used) is communicated through the
   Session-Time AVP in the response from the AAAH.

   Mobile Node   Foreign Agent       AAAF          AAAH      Home Agent
   -----------   -------------   ------------   ----------   ----------
                 Advertisement +
             <---Challenge
   Reg-Req(MN-AAA)->
                 AMR------------->
                                 AMR------------>
                                                HAR----------->
                                                          <----------HAA
                                            <-----------AMA
                             <------------AMA
             <-------Reg-Reply

              Figure 2: Mobile IP/DIAMETER Message Exchange

   The foreign agent depicted in figure 2 provides a challenge, which
   allows it to have direct control over the replay protection in the
   Mobile IP registration process, as described in [5]. The Challenge
   and MN-AAA authentication extension is used by the AAAH to
   authenticate the Mobile Node. If the value of the MN-AAA is invalid,
   the AAAH returns the AA-Mobile-Node-Answer (AMA, see section 2.2)
   with the Result-Code AVP set to an appropriate value.

   If the Mobile Node was successfully authenticated, the AAAH checks
   whether the Home-Agent-Address AVP specified a Home Agent. If one was
   specified, the AAAH must validate the address to ensure that it is a
   known Home Agent, and one that the Mobile Node is allowed to request.
   If no Home Agent was specified the AAAH SHOULD allocate one on behalf
   of the Mobile Node. This can be done in a variety of ways, including
   using a load balancing algorithm in order to keep the load on all
   Home Agents equal. The actual algorithm used and the method of
   discovering the Home Agents is outside of this specification.

   If the AMR's Mobile-Node-Address AVP did not specify an address, the
   AAAH has the option of assigning an address for the Mobile Node, or
   it can leave this up to the Home Agent. This is a local policy
   decision.

   The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains



Calhoun, Perkins          expires October 2000                  [Page 5]


INTERNET DRAFT                                                April 2000


   the Mobile IP Registration Request encapsulated in the MIP-
   Registration-Request AVP, to the assigned or requested Home Agent. If
   the Mobile-Node-Address AVP contains a NULL address (0.0.0.0), it is
   a request on behalf of the Mobile Node that a home address be
   assigned. The AAAH MAY manage the allocation of a home address for
   the mobile node, or leave the NULL address if it requires that the
   Home Agent perform the address assignment.

   Upon receipt of the HAR, the Home Agent processes the DIAMETER
   message as well as the Mobile IP Registration Request. If the
   DIAMETER message is invalid, a HAR is returned with the Result-Code
   AVP set to an appropriate value (see section 3.0). If the HAR is
   valid, the Home Agent processes the registration message and creates
   the Registration Reply, encapsulated within the MIP-Registration-
   Reply AVP. If a home address was requested, the Home Agent MUST
   assign one and include the address in both the Registration Reply and
   within the DIAMETER Mobile-Node-Address AVP. The DIAMETER response is
   then forwarded to the AAAH.

   Upon receipt of the HAA, the AAAH sets the Command-Code AVP to AA-
   Mobile-Node-Answer (AMA) to the AAAF. The AAAF is responsible for
   ensuring that the message is properly forwarded to the correct
   foreign agent.


1.3  Key Distribution Center

   If the AAAH is configured to act as a Key Distribution Center (KDC),
   the AAAH MUST create three short-lived keys when a Mobile Node is
   successfully authenticated and authorized. The three keys are used by
   the mobility entities to compute the three authentication extensions
   defined in [4]; Mobile-Foreign, Foreign-Home and Mobile-Home.

   The keys destined for each mobility entity are encrypted either using
   the secret shared with the entity [1], or via its public key [9]. The
   keys are encrypted using the security association shared with the
   entity in question. If the AAAH does not communicate directly with
   the Foreign Agent, the FA's keys are encrypted using the security
   association shared with the AAAF. The Session-Timeout AVP contains
   the number of seconds before the session keys expire. A value of zero
   indicates infinity (no timeout).

   KDC support requires a departure from the existing SPI usage, as
   described in [4]. The AAAH generates SPI values for the Mobility
   Agents as opposed to a receiver choosing its own SPI value. The SPI
   values are used as key identifiers, meaning that each short-lived
   session key has its own SPI value and since two nodes share a session
   key they share an SPI as well.



Calhoun, Perkins          expires October 2000                  [Page 6]


INTERNET DRAFT                                                April 2000


   Suppose a Mobile Node and a Foreign Agent share a key that was
   created by the AAAH. The AAAH also generated a corresponding SPI
   value of 37,496. All Mobile-Foreign Authentication extensions must be
   computed by either entity using the shared session key and MUST
   include the SPI value of 37,496.

   The AAAH MUST include all of the session keys in the HAR message sent
   to the Home Agent. If the HAR and the Registration Request are
   successfully processed, the Home Agent MUST include the Mobile Node's
   session keys in the Registration Reply [15], and the Foreign Agent's
   session keys in the HAA message (see section 2.4). The Registration
   Reply MUST include the Mobile-Home authentication extension using the
   session key distributed for that purpose by the AAAH. Similarly, the
   Reply SHOULD include the Foreign-Home authentication extension using
   the appropriate session key distributed by the AAAH.

   Upon receipt of the successful AA-Mobile-Node-Answer (AMA) the AAAF
   decrypts the FA-to-MN-Key and the FA-to-HA-Key AVPs. The AMA is
   transmitted to the Foreign Agent.

   Upon receipt of the AMA, the Foreign Agent decrypts its session keys
   found in the FA-to-MN-Key and FA-to-HA-Key, and validates the
   Foreign-Home authentication extension using the session key. The
   Foreign Agent MUST also include a Mobile-Foreign authentication
   extension using the newly distributed session key it shares with the
   Mobile Node.

   Once the session keys have been distributed to the three mobility
   entities, subsequent registrations do not need to invoke the AAA
   infrastructure unless the keys expire. These registrations MUST
   include the MN-FA, FA-HA and MN-HA authentication extensions. Figure
   3 provides an example of subsequent Mobile IP message exchange.

   Mobile Node                Foreign Agent                 Home Agent
   -----------                -------------                 ----------

   Reg-Req(MN-FA-Auth, MN-HA-Auth)-------->

                              Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->

                              <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)

   <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)

                   Figure 3: Mobile IP Message Exchange


1.4  Allocation of Home Agent in Foreign Network



Calhoun, Perkins          expires October 2000                  [Page 7]


INTERNET DRAFT                                                April 2000


   The DIAMETER Mobile IP extension allows a Home Agent to be allocated
   in a foreign network, as required in [3, 16]. When the AAAF receives
   the AMR message with a NULL address in the  Home-Agent-Address AVP,
   it MAY add the Foreign-Home-Agent-Available AVP to inform the AAAH
   that it is able and willing to assign a Home Agent for the Mobile
   Node. Upon receiving such a message, the AAAH must decide whether its
   local policy would allow the user to have a Home Agent in the foreign
   network.

   In the event that the AAAH is willing to let the Mobile Node have a
   Home Agent in the foreign network, it sends the AMA message to the
   AAAF with the Home-Agent-Address AVP set to the NULL address. The
   Home Agent's session keys MUST be encrypted using the security
   association the AAAH shares with the AAAF.

                            ISP                   Home Network
                        +--------+                 +--------+
                        |        |      AMR/A      |        |
                        |  AAAF  |<--------------->|  AAAH  |
                     +->| server |  server-server  | server |
                     |  +--------+  communication  +--------+
                     |          ^
               HAR/A |    AMR/A | client-server
                     |          | communication
                     v          v
             +---------+       +---------+
             |   Home  |       | Foreign |
             |  Agent  |       |  Agent  |
             +---------+       +---------+
                                ^
                                | Mobile IP
                                |
                                v
                              +--------+
                              | Mobile |
                              | Node   |
                              +--------+
             Figure 4: Home Agent allocated in Foreign Domain

   Upon receiving the message, the AAAF MUST re-encrypt both the Foreign
   and Home Agent's session keys, and forward the HAR message to a local
   Home Agent. The HAA is sent to the AAAF, which then forwards the
   answer to the AAAH. The return path is identical to the one
   previously defined in section 1.2. The HAA MUST be received by the
   AAAH, otherwise it has no assurances that service is being provided,
   and all subsequent accounting information could be rejected. The HAA
   is also used by the AAAH to receive the Home Address assigned to the
   Mobile Node. Figure 5 provides a message flow for a case where the



Calhoun, Perkins          expires October 2000                  [Page 8]


INTERNET DRAFT                                                April 2000


   Home Agent is allocated in the foreign domain.

   Mobile Node   Foreign Agent       AAAF       Home Agent       AAAH
   -----------   -------------  -------------   ----------    ----------

             <-------Challenge
   Reg-Req(Response)->
                 AMR------------->
                                 AMR-------------------------->
                                            <------------------------HAR
                                 HAR------------->
                                            <----------HAA
                                 HAA-------------------------->
                                            <------------------------AMA
                             <------------AMA
             <-------Reg-Reply
               Figure 5: Mobile IP/DIAMETER Message Exchange

   If the Mobile Node moves to another Foreign Network, it can either
   request to keep the same Home Agent within the old foreign network,
   or it can request that a new one be assigned. A non-NULL Home-Agent-
   Address AVP indicates that service from the same Home Agent is
   desired by the Mobile Node. When the Mobile Node requests such a
   service, the AAAH MUST interact with two AAAFs if it is willing to
   allow the Mobile Node to receive such service. The AAAH issues the
   HAR to the AAAF that oversees that Home Agent, and the AMA is issued
   to the AAAF that oversees the Foreign Agent.


1.5  DIAMETER Session Termination

   A Foreign and Home Agent assume that their respective DIAMETER
   servers maintain session state information for each mobile node in
   their networks.  In order for the DIAMETER Server to release any
   resources allocated to a specific mobile node, the mobility agents
   MUST send a Session-Termination-Request (STR) [1] to their respective
   DIAMETER servers.

   Since Mobile IP typically requires two Mobile Agents, the Home
   DIAMETER server SHOULD only free all resources when the STR was
   received from both the Foreign and the Home Agent. This ensures that
   a Mobile Node that moves from one Foreign Agent to another (hand-off)
   does not cause the Home DIAMETER Server to free all resources for the
   Mobile Node. The DIAMETER Server is free to initiate the session
   termination at any time by issuing the Session-Termination-Ind (STI)
   [1].

   Note that an exception to the above rule exists, where a Mobile Node



Calhoun, Perkins          expires October 2000                  [Page 9]


INTERNET DRAFT                                                April 2000


   is authenticated and/or authorized to access it's home network. The
   Mobile IP protocol allows this to occur, and does not require the
   presence of a Foreign Agent. Therefore, the Home DIAMETER Server MUST
   be aware of the fact that a Foreign Agent was involved in the
   authentication/authorization transaction.


2.0  Command-Code AVP Values

   This section defines Command-Code [1] values that MUST be supported
   by all DIAMETER implementations conforming to this specification.
   The following Command Codes are defined in this specification:

      Command-Name             Abbrev.    Code       Reference
      --------------------------------------------------------
      AA-Mobile-Node-Request    AMR       260           2.1
      AA-Mobile-Node-Answer     AMA       261           2.2
      Home-Agent-MIP-Request    HAR       262           2.3
      Home-Agent-MIP-Answer     HAA       263           2.4


2.1  AA-Mobile-Node-Request (AMR) Command

   The AA-Mobile-Node-Request (AMR), indicated by the Command-Code AVP
   set to 260, is sent by a Foreign Agent acting as a DIAMETER client to
   a server to request the authentication and authorization of a Mobile
   Node. The Foreign Agent uses information found in the Registration
   Request to construct the AMR such as the home address (Mobile-Node-
   Address AVP), home agent address (Home-Agent-Address AVP), mobile
   node NAI (User-Name AVP [1]). If the home address is set to a NULL
   address (0.0.0.0), it is an indication that the Mobile Node wishes to
   have a home address assigned to it in the Registration Reply.

   If the AMR message includes a Foreign-Home-Agent-Available AVP and
   the Home-Agent-Address AVP has a NULL address, it is an indication
   that the AAAF is willing to assign a Home Agent in the foreign
   domain.

   If the Previous-FA-NAI AVP is found in the request, the DIAMETER
   client requests that the server return the session key that was
   assigned to the previous Foreign Agent for use with the Mobile Node
   and Home Agent. The session key is identified through the use of the
   Mobile-Node-Address AVP.

   Message Format






Calhoun, Perkins          expires October 2000                 [Page 10]


INTERNET DRAFT                                                April 2000


      <AA-Mobile-Node-Request>  ::= <DIAMETER Header>
                                    <Command-Code AVP = 260>
                                    <Session-ID AVP>
                                    <User-Name AVP>
                                    <Host-Name AVP>
                                    [<Destination-NAI AVP>]
                                    <MIP-Registration-Request AVP>
                                    <MN-FA-Challenge-Length AVP>
                                    <MN-FA-Response AVP>
                                    <Mobile-Node-Address AVP>
                                    <Home-Agent-Address AVP>
                                    <MN-AAA SPI AVP>
                                    [<Foreign-Home-Agent-Available AVP>]
                                    [<FA-MN-Preferred-SPI>]
                                    [<FA-HA-Preferred-SPI>]
                                    [<Previous-FA-NAI AVP>]
                                    [<Proxy-State [1] AVP>]
                                    [<Timestamp AVP>
                                     <Nonce AVP>
                                     <Integrity-Check-Value AVP>]


2.2  AA-Mobile-Node-Answer (AMA) Command

   The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code AVP
   set to 261, is sent by the AAAH in response to the AA-Mobile-Node-
   Request message. A successful response MUST include the MIP-
   Registration-Reply AVP. The Result-Code AVP MAY contain one of the
   values defined in section 3.0, in addition to the values defined in
   [1].

   The Home-Agent-Address AVP contains the Home Agent assigned to the
   Mobile Node, while the Mobile-Node-Address AVP contains the home
   address that was assigned. A successful response MUST NOT have either
   AVP set to a NULL address.

   The AMA message MUST contain the optional FA-to-HA-Key, FA-to-MN-Key
   and MIP-Registration-Reply AVPs if they were present in the HAA
   message.

   Message Format










Calhoun, Perkins          expires October 2000                 [Page 11]


INTERNET DRAFT                                                April 2000


      <AA-Mobile-Node-Answer>  ::= <DIAMETER Header>
                                   <Command-Code AVP = 261>
                                   <Session-Id AVP>
                                   <Host-Name AVP>
                                   <Destination-NAI AVP>
                                   <Result-Code AVP>
                                   [<MIP-Registration-Reply AVP>]
                                   [<FA-to-MN-Key AVP>]
                                   [<FA-to-HA-Key AVP>]
                                   <Home-Agent-Address AVP>
                                   <Mobile-Node-Address AVP>
                                   <Session-Timeout AVP>
                                   [<Proxy-State AVP>]
                                   [<Timestamp AVP>
                                    <Nonce AVP>
                                    <Integrity-Check-Value AVP>]


2.3  Home-Agent-MIP-Request (HAR) Command

   The Home-Agent-MIP-Request (HAR), indicated by the Command-Code AVP
   set to 262, is sent by the AAAH to the Home Agent. If the Home Agent
   is to be assigned in a foreign network, the HAR is issued to the AAAF
   overseeing the Home Agent. If the HAR message includes a NULL home
   address in the Mobile-Node-Address AVP and the request is
   successfully processed, the Home Agent MUST allocate one such address
   to the mobile node.

   If a AAAF receives a HAR with the Mobile-Home-Agent AVP set to a NULL
   address, it is a request that a Home Agent be assigned in the foreign
   network.

   If the AAAH is configured as a Key Distribution Center (see section
   1.3), the AAAH MUST create the session keys and include them in the
   HAR message.

   Message Format














Calhoun, Perkins          expires October 2000                 [Page 12]


INTERNET DRAFT                                                April 2000


      <Home-Agent-MIP-Request>  ::= <DIAMETER Header>
                                    <Command-Code AVP = 262>
                                    <Session-Id AVP>
                                    <Host-Name AVP>
                                    <User-Name AVP>
                                    [<Destination-NAI AVP>]
                                    <MIP-Registration-Request AVP>
                                    [<HA-to-MN-Key AVP>]
                                    [<MN-to-HA-Key AVP>]
                                    [<HA-to-FA-Key AVP>]
                                    [<MN-to-FA-Key AVP>]
                                    [<FA-to-HA-Key AVP>]
                                    [<FA-to-MN-Key AVP>]
                                    <Home-Agent-Address AVP>
                                    <Mobile-Node-Address AVP>
                                    <Session-Timeout AVP>
                                    [<Proxy-State AVP>]
                                    [<Timestamp AVP>
                                     <Nonce AVP>
                                     <Integrity-Check-Value AVP>]


2.4  Home-Agent-MIP-Answer (HAA) Command

   The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code AVP
   set to 263, is sent by the Home Agent to its local AAA server in
   response to a Home-Agent-MIP-Request. In the event that this message
   is sent to an AAAF in a foreign network, the message MUST be
   forwarded to the AAAH.  The Result-Code AVP MAY contain one of the
   values defined in section 3.0, in addition to the values defined in
   [1].

   The HAA message MUST contain the optional FA-to-HA-Key and FA-to-MN-
   Key AVPs if they were present in the HAR message.

   Message Format















Calhoun, Perkins          expires October 2000                 [Page 13]


INTERNET DRAFT                                                April 2000


      <Home-Agent-MIP-Answer>  ::= <DIAMETER Header>
                                   <Command-Code AVP = 263>
                                   <Session-Id AVP>
                                   <Host-Name AVP>
                                   <Destination-NAI AVP>
                                   <Result-Code AVP>
                                   <MIP-Registration-Reply AVP>
                                   <Mobile-Node-Address AVP>
                                   <Home-Agent-Address AVP>
                                   [<FA-to-HA-Key AVP>]
                                   [<FA-to-MN-Key AVP>]
                                   [<Proxy-State AVP>]
                                   [<Timestamp AVP>
                                    <Nonce AVP>
                                    <Integrity-Check-Value AVP>]


3.0 Result-Code AVP Values

   This section defines new Result-Code [1] values that MUST be
   supported by all DIAMETER implementations that conform to this
   specification.

      DIAMETER_ERROR_BAD_KEY             16
         This error code is used by the Home Agent to indicate to the
         local DIAMETER server that the key generated is invalid.

      DIAMETER_ERROR_BAD_HOME_ADDRESS    17
         This error code is used by the Home Agent to indicate that the
         Home Address chosen by the Mobile Node or assigned by the local
         DIAMETER server is unavailable.

      DIAMETER_ERROR_TOO_BUSY            18
         This error code is used by the Home Agent to inform the
         DIAMETER Server that it cannot handle an extra Mobile Node.
         Upon receiving this error the DIAMETER Server can try to use an
         alternate Home Agent if one is available.

      DIAMETER_ERROR_MIP_REPLY_FAILURE   19
         This error code is used by the Home Agent to inform the
         DIAMETER server that the Registration Request failed.


4.0  Mandatory AVPs

   The following table describes the DIAMETER AVPs defined in the Mobie
   IP extension, their AVP Code values, types, possible flag values and
   whether the AVP MAY be encrypted.



Calhoun, Perkins          expires October 2000                 [Page 14]


INTERNET DRAFT                                                April 2000


                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP   Section  Value     |    |     |SHLD| MUST|May |
   Attribute Name  Code  Defined  Type      |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----+
   MIP-             320     4.1    Data     | M  |  P  |    | T,V | Y  |
     Registration-Request                   |    |     |    |     |    |
   MIP-             321     4.2    Data     | M  |  P  |    | T,V | Y  |
     Registration-Reply                     |    |     |    |     |    |
   MN-FA-Challenge- 322     4.3    Integer32| M  |  P  |    | T,V | Y  |
     Length                                 |    |     |    |     |    |
   MN-FA-Response   323     4.4    Data     | M  |  P  |    | T,V | Y  |
   Mobile-Node-     333     4.5    Address  | M  |  P  |    | T,V | Y  |
     Address                                |    |     |    |     |    |
   Home-Agent-      334     4.6    Address  | M  |  P  |    | T,V | Y  |
     Address                                |    |     |    |     |    |
   Previous-FA-NAI  335     4.7    String   | M  |  P  |    | T,V | Y  |
   Foreign-Home-    337     4.8    Integer32| M  |  P  |    | T,V | Y  |
     Agent-Available                        |    |     |    |     |    |
   MN-AAA-SPI       336     4.9    Integer32| M  |  P  |    | T,V | Y  |


4.1  MIP-Registration-Request AVP

   The MIP-Registration-Request AVP (AVP Code 320) is of type data and
   contains the Mobile IP Registration Request [4] sent by the Mobile
   Node to the Foreign Agent.


4.2  MIP-Registration-Reply AVP

   The MIP-Registration-Reply AVP (AVP Code 321) is of type data and
   contains the Mobile IP Registration Reply [4] sent by the Home Agent
   to the Foreign Agent.


4.3  MN-FA-Challenge-Length AVP

   The MN-FA-Challenge-Length AVP (AVP Code 322) is of type Interger32
   and contains the number of octets in the MIP-Registration-Request AVP
   that are to be used by the AAAH as the challenge value used in the
   computation of the Response (see section 4.4).


4.4  MN-FA-Response AVP

   The MN-FA-Response AVP (AVP Code 323) is of type data and contains



Calhoun, Perkins          expires October 2000                 [Page 15]


INTERNET DRAFT                                                April 2000


   the authenticator field of the Mobile Node's challenge response found
   in the Mobile IP MN-AAA authentication extension [5]. The
   authenticator is the value computed by the mobile node using the
   Registration Request and the security association shared with its
   AAAH. This AVP is used to authenticate the Mobile Node.

   The data field contains the mobile node's challenge response and is
   used to authenticate the mobile node. Although any authentication
   algorithm can be used, all implementations MUST support MD5's
   prefix+suffix mode, as described in [5], and MAY support the HMAC
   mode. The challenge value used in the computation is found in the
   MIP-Registration-Request AVP. The length of the challenge is found in
   the MN-FA-Challenge-Length AVP.


4.5  Mobile-Node-Address AVP

   The Mobile-Node-Address AVP (AVP Code 333) is of type Address and
   contains the Mobile Node's Home Address. When this AVP has a NULL
   Address (0.0.0.0), it is a request that a Home Address be allocated
   to the Mobile Node.


4.6  Home-Agent-Address AVP

   The Home-Agent-Addess AVP (AVP Code 334) is of type Address and
   contains the Mobile Node's Home Agent Address. When this AVP has a
   NULL address (0.0.0.0), it is a request that a Home Agent be
   allocated to the Mobile Node. If this AVP is set to the NULL address
   in the AMA message, it is an indication that a Home Agent MUST be
   allocated in the foreign network. If the address is set to
   255.255.255.255 in the AMR, it is a request from the Mobile Node that
   the Home Agent MUST be allocated only within the home network.


4.7  Previous-FA-NAI AVP

   The Previous-FA-NAI AVP (AVP Code 335) is of type String and contains
   the Network Access Identifier [6] of the Mobile Node's old Foreign
   Agent.  The Mobile Node will include this information in the
   Registration Request when it moves it point of attachment to a new
   foreign agent under the same administrative domain as the old FA
   (identified by the domain part of the NAI).

   When this AVP is present in the AA-Mobile-Node-Request, it indicates
   that the local DIAMETER server overseeing the Foreign Agent should
   attempt to return the session key that was previously allocated to
   the old Foreign Agent for the Mobile Node. The session key is



Calhoun, Perkins          expires October 2000                 [Page 16]


INTERNET DRAFT                                                April 2000


   identified through the use of the Mobile-Node-Address AVP, which MUST
   be present if this extension is present.

   This allows the Mobile Node to move from one Foreign Agent to another
   within the same administrative domain without having to send the
   request back to the Mobile Node's Home DIAMETER Server.


4.8  Foreign-Home-Agent-Available AVP

   The Foreign-Home-Agent-Available AVP (AVP Code 337) is of type
   Integer32 and is added with a value of one by the AAAF owned by the
   same administrative domain as the Foreign Agent if it is willing and
   able to allocate a Home Agent within the Foreign network for the
   Mobile Node.

   If this extension is present in the AMR and the Home-Agent-Address
   AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a Home
   Agent for the Mobile Node. This is done by including the Home-Agent-
   Address AVP with a value of 0.0.0.0 in the AMR.


4.9  MN-AAA-SPI AVP

   The MN-AAA-SPI AVP (AVP Code 336) is of type Integer32 and is sent in
   the AA-Mobile-Node-Request by the Foreign Agent, and contains the SPI
   value found in the Mobile-IP MN-AAA Authentication Extension [5]. The
   SPI can be used by the AAAH to identify the security context to use
   in order to authenticate the Mobile Node. When possible, it is
   recommended that the AAAH makes use of the Mobile Node's NAI to
   identify the security context, when possible.


5.0  Key Distribution Center (KDC) AVPs

   The Mobile-IP protocol defines a set of security associations shared
   between the Mobile Node, Foreign Agent and Home Agents. These three
   security associations (MN-FA, MN-HA and FA-HA), can be dynamically
   created by the AAAH. This requires that the AAAH create Mobile-IP
   Session Keys, and that these keys be distributed to the three mobile
   entities, via the DIAMETER Protocol. The KDC AVPs SHOULD be
   supported.

   When Key Distribution Center services are required, the AAAH creates
   three session keys; the MN-FA, MN-HA and the FA-HA keys. Each of
   these keys are encrypted two different ways, one for each key
   recipient. The mobile node and home agent Session Keys are sent to
   the Home Agent, while the foreign agent's keys are sent to the



Calhoun, Perkins          expires October 2000                 [Page 17]


INTERNET DRAFT                                                April 2000


   foreign agent via the AAAF.

   If strong authentication and confidentiality of the session keys is
   required, it is recommended that the strong security extension [9] be
   used.

   The following table describes the DIAMETER AVPs defined in the Mobie
   IP extension, their AVP Code values, types, possible flag values and
   whether the AVP MAY be encrypted.

                                             +---------------------+
                                             |    AVP Flag rules   |
                                             |----+-----+----+-----|----+
                    AVP   Section  Value     |    |     |SHLD| MUST|MAY |
    Attribute Name  Code  Defined  Type      |MUST| MAY | NOT|  NOT|Encr|
    -----------------------------------------|----+-----+----+-----|----+
    MN-to-FA-Key     325     5.1    Complex  | M  |  P  |    | T,V | Y  |
    MN-to-HA-Key     331     5.1    Complex  | M  |  P  |    | T,V | Y  |
    FA-to-MN-Key     326     5.2    Complex  | M  |  P  |    | T,V | Y  |
    FA-to-HA-Key     328     5.2    Complex  | M  |  P  |    | T,V | Y  |
    HA-to-MN-Key     332     5.2    Complex  | M  |  P  |    | T,V | Y  |
    HA-to-FA-Key     329     5.2    Complex  | M  |  P  |    | T,V | Y  |
    FA-MN-Preferred- 324     5.3    Integer32| M  |  P  |    | T,V | Y  |
      SPI                                    |    |     |    |     |    |
    FA-HA-Preferred- 327     5.4    Integer32| M  |  P  |    | T,V | Y  |
      SPI                                    |    |     |    |     |    |



5.1  Mobile Node Session Key AVP

   The session keys AVPs destined for the Mobile Node are of type
   complex, and are created by the AAAH. There are two Mobile Node
   Session Key AVPs; the MN-FA Key and the MN-HA Key.

   The MN-FA-Key AVP (AVP Code 325) contains the data immediately
   following the Mobile IP extension header of the "Unsolicited MN-FA
   Key From AAA Subtype", as documented in [15].

   The MN-HA-Key AVP (AVP Code 331) contains the data immediately
   following the Mobile IP extension header of the "Unsolicited MN-HA
   Key From AAA Subtype", as documented in [15].

   The AAA SPI field of the Mobile IP session keys are set to the value
   the AAAH shares with the Mobile Node. The MN-HA-Key's HA SPI field
   contains the same value as the one found in the HA-MN-Key AVP.  The
   MN-FA-Key's FA SPI field contains the same value as the one found in
   the FA-MN-Key AVP. The session key's Lifetime field is set to the



Calhoun, Perkins          expires October 2000                 [Page 18]


INTERNET DRAFT                                                April 2000


   same value as the one found in the Session-Timeout AVP.


5.2  Mobility Agent Session Key AVPs

   The session keys AVPs destined for the Foreign and Home Agents are of
   type complex, and MUST have the AVP length field set to at least 13.
   The AVP has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 AVP Header
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Peer SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Code
         326 for FA-MN Key, destined for Foreign Agent
         328 for FA-HA Key, destined for Foreign Agent
         329 for HA-FA Key, destined for Home Agent
         332 for MN-HA Key, destined for Home Agent

      Peer SPI
         A 32-bit opaque value, which the target MUST use to index all
         the necessary information recovered from the security
         information after it is decoded.

      Data
         The data field contains the key used to create a Mobility
         Security Association between the mobility nodes.


5.3  FA-MN-Preferred-SPI AVP

   The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is
   sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP
   contains the SPI that the Foreign Agent would prefer to have assigned
   by the AAAH in the FA-to-MN-Key AVP.


5.4  FA-HA-Preferred-SPI AVP

   The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is
   sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP
   contains the SPI that the Foreign Agent would prefer to have assigned



Calhoun, Perkins          expires October 2000                 [Page 19]


INTERNET DRAFT                                                April 2000


   by the AAAH in the FA-to-HA-Key AVP.


6.0  Interactions with Resource Management

   The Resource Management extension [31] provides the ability for a
   DIAMETER node to query a peer for session state information. The
   document states that service-specific extensions are responsible for
   specifying what AVPs are to be present in the Resource-Token [31]
   AVP.

   In addition to the AVPs listed in [31], the Resource-Token with the
   Extension-Id AVP set to four (4) MUST include the Mobile-Node-Address
   and the Home-Agent-Address AVP.


7.0  Acknowledgements

   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the Document Reading Party.
   The authors would also like to thank the participants of TIA's TR45.6
   working group for their valuable feedback.


8.0  IANA Considerations

   The command codes defined in Section 2.0 are values taken from the
   Command-Code AVP [1] address space and extended in [9], [12] and
   [17].  IANA should record the values as defined in Section 2.0.

   The Result-Code values defined in Section 3.0 are error codes as
   defined in [1] and extended in [9], [12] and [17]. They correspond to
   error values specific to the Mobile IP extension. IANA should record
   the values as defined in Section 3.0.

   The AVPs defined in sections 4.0 and 5.0 were alllocated from from
   the AVP numbering space defined in [1], and extended in [9], [12] and
   [17]. IANA should record the values as defined in Sections 4.0 and
   5.0.


9.0  Security Considerations

   This specification describes the DIAMETER extension necessary to
   authenticate and authorize a Mobile IP Mobile Node. The
   authentication algorithm used is dependent upon the transforms
   available by the Mobile IP protocol, and [5]. This specification also
   defines a method by which the home DIAMETER server can create and



Calhoun, Perkins          expires October 2000                 [Page 20]


INTERNET DRAFT                                                April 2000


   distribute short-lived session keys to be used to authenticate Mobile
   IP registration messages. The keys are distributed in an encrypted
   format through the DIAMETER protocol, and SHOULD be encrypted using
   the methods defined in [9].


10.0  References


   [1]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base
        Protocol", draft-calhoun-diameter-13.txt, IETF work in progress,
        March 2000.

   [2]  Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun-
        diameter-framework-07.txt, IETF work in progress, April 2000.

   [3]  S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
        Authorization, and Accounting Requirements", draft-ietf-
        mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000.

   [4]  C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996.

   [5]  C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten-
        sions", draft-ietf-mobileip-challenge-09.txt, IETF work in pro-
        gress, February 2000.

   [6]  B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486.
        January 1999.

   [7]  B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols",
        RFC 2477, January 1999.

   [8]  P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier
        Extension", draft-ietf-mobileip-mn-nai-07.txt, IETF work in pro-
        gress, January 2000.

   [9]  P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
        Extensions", draft-calhoun-diameter-strong-crypto-03.txt, IETF
        work in progress, April 2000.

   [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
        2406, November 1998.

   [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting
        Extension", draft-calhoun-diameter-accounting-05.txt, IETF work



Calhoun, Perkins          expires October 2000                 [Page 21]


INTERNET DRAFT                                                April 2000


        in progress, April 2000.

   [13] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
        for Message Authentication.  RFC 2104, February 1997.

   [14] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
        1996.

   [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP",
        draft-calhoun-mobileip-aaa-keys-01.txt, IETF work in progress,
        January 2000.

   [16] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA",
        draft-hiller-cdma2000-AAA-00.txt, IETF work in progress, October
        1999.

   [17] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
        Extension", draft-calhoun-diameter-nasreq-03.txt, IETF work in
        progress, April 2000.


11.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  +1 650-786-7733
         Fax:  +1 650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Charles E. Perkins
      Nokia Research Center
      313 Fairchild Drive
      Mountain View, California 94043
      USA

      Phone:  +1 650-625-2986
        Fax:  +1 650-691-2170
      E-Mail: charliep@iprg.nokia.com





Calhoun, Perkins          expires October 2000                 [Page 22]


INTERNET DRAFT                                                April 2000


12.0  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 docu-
   ment 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 develop-
   ing 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 languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.



























Calhoun, Perkins          expires October 2000                 [Page 23]


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