Subject: [AAA-WG]: [Fwd: Issue #299 and #301]

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 15:28:42 -0800

I'm sorry if you receive this twice......

/Tony

-------- Original Message --------
Subject: Issue #299 and #301
   Date: Mon, 01 Apr 2002 11:53:07 -0800
   From: Tony Johansson <[email-masked]>
     To: [email-masked]

All,

I have worked on new  proposed text for issue 299 and 301, see below,
based on the solution we agree upon at the IETF 53. Part of this
solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines
the needed AAAH NAI and the HA NAI, please see
http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt.
The draft have been submitted to the mobileip wg and will go to wg final
call if no major comments/issues are found on the mobileip wg list.

I hope this solves the issue 299 and 301, however I need help to
understand how I should deal the newly submitted issue #321 regarding
CMS. Is it good enough to just move the CMS ref to informative?

Comments please.

/Tony

Added to to section 1.0:

"1.0  Introduction

 ...

   Furthermore, the nature of mobile IP also means that the mobile node
   will do handoffs between different foreign agents and to guarantee
   that a registered user always ends up in the same initial AAAH the
   Mobile Node MUST always include the home NAI and the AAAH NAI
   [AAANAI].

 ... "

I've made changes here and there in section 1.2, 1.3 and 1.4, so here is
the whole text...

" 1.2  Inter-Realm Mobile IP

   When a Mobile Node node requests service by issuing a Registration
   Request to the foreign agent, the foreign agent 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 for
   possible inclusion as Diameter AVPs.  The AMR message is then
   forwarded to the local Diameter server, known as the AAA-Foreign, or
   AAAF.

                   Visited Realm                    Home Realm
                     +--------+                     +--------+
                     |abc.com |       AMR/AMA       |xyz.com |
                     |  AAAF  |<------------------->|  AAAH  |
                  +->| server |    server-server    | server |
                  |  +--------+    communication    +--------+
                  |         ^                         ^
                  | AMR/AMA |      client-server      | HAR/HAA
                  |         |      communication      |
                  v         v                         v
          +---------+      +---------+              +---------+
          | Foreign |      | Foreign |              |  Home   |
          |  Agent  |      |  Agent  |              |  Agent  |
          +---------+      +---------+              +---------+
                            ^
                            | Mobile IP
                            |
                            v
                           +--------+
                           | Mobile |
                           | Node   | [email-masked]
                           +--------+
                      Figure 1: Inter-Realm Mobility

   Upon receiving the AMR, the AAAF follows the procedures outlined in
   [DIAMBASE] 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 shows an example in which a mobile node
   ([email-masked]) requests service from a foreign provider (abc.com). The
   request received by the AAAF is forwarded to xyz.com's AAAH server.

Figure 2 shows 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 AAA services every time a Registration Request
   is received from the mobile, but rather only when the prior
   authorization from the AAAH expires. The expiration time of the
   authorization is communicated through the Authorization-Lifetime AVP
   in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH.

   Mobile Node   Foreign Agent       AAAF          AAAH      Home Agent
   -----------   -------------   ------------   ----------   ----------
                 Advertisement &
        <--------- Challenge

   Reg-Req&MN-AAA  ---->

                      AMR------------>
                      Session-Id = foo

                                     AMR------------>
                                     Session-Id = foo

                                                   HAR----------->
                                                   Session-Id = bar

                                                     <----------HAA
                                                   Session-Id = bar

                                       <-----------AMA
                                       Session-Id = foo

                        <------------AMA
                        Session-Id = foo

        <-------Reg-Reply

              Figure 2: Mobile IP/Diameter Message Exchange

   The foreign agent (as shown in Figure 2) MAY provide a challenge,
   which gives it direct control over the replay protection in the
   Mobile IP registration process, as described in [MIPCHAL].  The
   mobile node includes the Challenge and MN-AAA authentication
   extension to enable authorization by AAAH. If the authentication data

   supplied in the MN-AAA extension is invalid, AAAH returns the
   response (AMA) with the Result-Code AVP set to
   DIAMETER_AUTHENTICATION_REJECTED.

   A mobile node, which has been previously authenticated andauthorized,

   MUST always include the assigned home agent in the HA-NAI
   and the authorizing Home AAA server in the AAAH-NAI in the
   registration request message [AAANAI] sent to the FA, every time the
   Mobile Node needs to re-authenticating. So, in the event that the AMR

   generated by the FA is for a session that has was previously
   authorized, it MUST include the Destination-Host AVP, with the
   identity of the AAAH found in the AAAH-NAI and the MIP-Home-Agent-
   Host AVP the identity of the assigned HA found in the HA-NAI.

   If the mobile node was successfully authenticated, the AAAH checks if

   the Home Agent was located in the foreign realm, by checking the MIP-

   Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the
   Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If
   home agent is located in the foreign realm, then AAAH sends an HAR
   message to the home agent, which contains a MIP-Reg-Request AVP.

   If the home agent was not located in the foreign realm, the AAAH
   checks for the MIP-Home-Agent-Address AVP and if present the MIP-
   Home-Agent-Host AVP. If one was specified, the AAAH checks that the
   address is that of a known home agent and that the Mobile Node is
   allowed to request this particular home agent, and that the home
   agent's identity is included in the MIP-Home-Agent-Host AVP. If no
   home agent was specified, and if the MIP-Feature-Vector has the Home-

   Agent-Requested flag set, and if allowed by policy in the home realm,

   the AAAH SHOULD allocate a home agent 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 the scope of this specification.

   The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains
   the Mobile IP Registration Request message data encapsulated in the
   MIP-Reg-Request AVP, to the assigned or requested Home Agent. The
   AAAH MAY allocate a home address for the mobile node, while the Home
   Agent MUST support home address allocation. In the event the AAAH
   handles address allocation, it includes it in a MIP-Mobile-Node-
   Address AVP within the HAR.  The absence of this AVP informs the Home

   Agent to perform the allocation.

   During the creation of the HAR, the AAAH MUST use a different session

   identifier than the one used in the AMR/AMA (see Figure 2). If the
   AAAH is session-stateful, it MUST send the same session identifier
   for all HARs initiated on behalf of a given mobile node's session.
   Otherwise, if the AAAH is session-stateless, it will manufacture a
   unique session-id for every HAR.

A mobile node's session is identified via its identity in the User-
   Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address
   AVPs. This is necessary in order to allow the session state machine,
   defined in the base protocol [DIAMBASE], to be used unmodified with
   this application. Therefore, an STR from a foreign agent would free
   the session from the foreign agent, but not the one towards the home
   agent (see figure 3).

           STR, Session-Id = foo       STR, Session-Id = bar
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           STA, Session-Id = foo       STA, Session-Id = bar
            Figure 3: Session Termination and Session Identifiers

   Upon receipt of the HAR, the home agent first processes the Diameter
   message. The home agent processes the MIP-Reg-Request AVP and creates

   the Registration Reply, encapsulating it within the MIP-Reg-Reply
   AVP. In the creation of the Registration Reply the Home Agent must
   include the HA NAI and the AAAH NAI, which will be created from the
   Originating-Host AVP and Originating-Realm AVP of the HAR. If a home
   address is needed, the home agent MUST also assign one and include
   the address in both the Registration Reply and within the MIP-Mobile-

   Node-Address AVP.

   The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA
   returned to the AAAH.

   Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
   (AMA) message, includes the Accounting-Multi-Session-Id that was
   present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-
   Address AVPs in the AMA message, enabling appropriate firewall
   controls for the penetration of tunneled traffic between the Home
   Agent and the Mobile Node.

   The AAAF is responsible for ensuring that the AMA message is properly

   forwarded to the correct foreign agent.

1.3  Support for Mobile IP Handoffs

   Given the nature of Mobile IP, a mobile node MAY receive service from

   many foreign agents during a period of time. However, the home realm
   should not view these handoffs as different sessions, since this
   could affect billing systems. Furthermore, many foreign agents do not

   communicate, which makes it quite difficult for AAA information to be

   exchanged between these entities. Therefore, it MUST be assumed that
   a foreign agent is not aware that a registration request from a
   mobile node has been previously authorized.

   The first registration request from a mobile node will therefore
   cause an AMR to be sent to its AAAF. The AMR will include a new
   session identifier, and MAY even be sent to a different AAAF in the
   visited network.

   Since the AAAH may be session-stateless, it is necessary for the
   resulting HAR received by the HA to be identified as a continuation
   of an existing session. If the HA receives an HAR for a mobile node,
   with a new session identifier, and the HA can guarantee that this
   request is to extend service for an existing service, then the HA
   MUST be able to modify its internal session state information to
   reflect the new session identifier.

   It is necessary for accounting records to have some commonality
   across handoffs in order for correlation to occur.  Therefore, the
   home agent MUST send the same Accounting-Multi-Session-Id AVP value
   in all HAAs for the mobile's session.  That is, the HA generates a
   unique Accounting-Multi-Session-Id when receiving an HAR for a new
   session, and returns this same value in every HAA for the session.
   This Accounting-Multi-Session-Id AVP will be returned to the foreign
   agent by the AAAH in the AMA. Both the foreign and home agents MUST
   include the Accounting-Multi-Session-Id in the accounting messages.

           ACR, Session-Id = foo         ACR, Session-Id = bar
       Accounting-Multi-Session-Id = a   Accounting-Multi-Session-Id = a

           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           ACA, Session-Id = foo       ACA, Session-Id = bar

            Figure 4: Accounting messages w/ Mobile IP Application

1.4  Allocation of Home Agent in Foreign Network

   The Diameter Mobile IP application allows a home agent to be
   allocated in a foreign network, as required in [MIPREQ, CDMA2000].
   When a foreign agent detects that the mobile node has a home agent
   address equal to 0.0.0.0 or 255.255.255.255 in the Registration
   Request message, it MUST add a MIP-Feature-Vector AVP with the Home-
   Agent- Requested flag set to one. If the home agent address is equal
   to 255.255.255.255, then the foreign agent also MUST set the Home-
   Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home

   agent address is set to 0.0.0.0, the foreign agent MUST set the Home-

   Address-Allocatable-Only-in-Home-Realm flag equal to zero.

   When the AAAF receives an AMR message with the Home-Agent-Requested
   flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm
   flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available

   flag in the MIP-Feature-Vector AVP to inform the AAAH that it is
   willing and able to assign a Home Agent for the Mobile Node. When
   doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP

   and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-
   Agent-Host AVP contains the identity of the home agent that would be
   assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP
   contains the identity of the AAAF.

   In the event that the mobile node has been previously authorized by
   the AAAH and now needs to be re-authenticated, and requests to keep
   the assigned home agent in the foreign network, the mobile node MUST
   include the HA NAI and the AAAH NAI in the registration request to
   the FA. Upon receipt, the FA will in create the AMR including the
   MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the
   AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include

   the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF
   authorizes the use of the requested home agent, the AAAF MUST set the

   Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.

   When the AAAH receives an AMR message, it first checks the
   authentication data supplied by the mobile node, according to the
   MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether
   to authorize the mobile node.  If the AMR indicates that the AAAF has

   offered to allocate a Home Agent for the mobile node, i.e. the
   Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or

   the AMR indicates that the AAAF has offered a previously allocated
   Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign-
   Network is set in the MIP-Feature-Vector AVP, then the AAAH must
   decide whether its local policy would allow the user to have a Home
   Agent in the foreign network or to keep the Home Agent in the foreign

   network. If so, and after checking authorization from the data in the

   AMR message, the AAAH sends the HAR message to Home Agent byincluding

   the Destination-Host AVP set to the value found in the
   AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if

   the HA has been previously allocated and authorized by the AAAH. If
   the HA has not been previously allocated by the foreign domain, the
   HAR sent by the AAAH does not contain the MIP-Home-Agent-Address.

   The HAR sent by the AAAH back to the foreign realm with the
   Destination-Host AVP set to the home agents identity, may not
   necessarily be received by the same AAAF, which sent the AMR.
   Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA
   AVP from the AMR message to the HAR message. In cases when another
   AAAF receives the HAR, the new AAAF will use the MIP-Originating-
   Foreign-AAA AVP for policy decisions, such as determining if the FA-
   HA Key should be encrypted or not. If on the other hand, the AAAH
   local policy determines that the MN-HA Key and the MN-FA Key must be
   encrypted and no security association is known to the home agent, the

   AAAH SHOULD send the HAR to the originating AAAF by including the
   Destination-Host AVP set to the value found in the AMR's MIP-
   Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or
   the MIP-Candidate-Home-Agent-Host AVP found in the AMR.

                           Visited                           Home
                            Realm                           Realm
                          +--------+ ------- AMR -------> +--------+
                          |  AAAF  | <------ HAR -------- |  AAAH  |
                          |        |                      |        |
                     +--->| server | ------- HAA -------> | server |
                     |    +--------+ <------ AMA -------- +--------+
                     |         ^  |
                     |         |  |
             HAR/HAA |     AMR |  | AMA
                     v         |  v
             +---------+       +---------+
             |   Home  |       | Foreign |
             |  Agent  |       |  Agent  |
             +---------+       +---------+
                                       ^
                  +--------+           |
                  | Mobile |<----------+
                  | Node   |  Mobile IP
                  +--------+
              Figure 5: Home Agent allocated in Visited Realm

   Upon receipt of a HAA from the Home Agent in the visited realm, the
   AAAF forwards the HAA to the AAAH in the home realm. The AMA is then
   constructed, and issued to the AAAF, and finally to the FA. If the
   Result-Code indicates success, the HAA and AMA MUST include the MIP-
   Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.

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

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

   If the Mobile Node moves to another Foreign Network, it MAY either
   request to keep the same Home Agent within the old foreign network,
   or request to get a new one in the new foreign network. If the AAAH
   is willing to provide the requested service, the mobile node will
   have to interact with two AAAFs.

   Figure 7 shows the message flows for a Mobile Node requesting to keep

   the Home Agent assigned in Foreign network 1 when it moves to foreign

   network 2. Upon reception of the AMR in Foreign network 2, the AAAF
   follows the procedures described earlier and forwards AMR to the
   Mobile Node's home network, i.e. its AAAH. If the Mobile Node was
   successfully authenticated, the AAAH checks the identity of the
   foreign and home agent to determine whether the user is in a third
   realm. If this is the case, the AAAH must check whether the mobile is

   still permitted to use the previously assigned Home Agent.

                   +---------------+ +---------------+ +-------------+
                   |Foreign net 2  | |Foreign net 1  | |Home network |
                   |               | |               | |             |
      Mobile Node  |  FA      AAAF | |  HA     AAAF  | |    AAAH     |
      -----------  | ----     ---- | | ----   ------ | |   ------    |
                   +---------------+ +---------------+ +-------------+

      <----Challenge----
      Reg-Req (Response)->
                       ---AMR--->
                                ----------------AMR--------------->
                                                     <-----HAR-----
                                        <---HAR----
                                        ----HAA--->
                                                     ------HAA---->
                                <---------------AMA----------------
                       <--AMA----
       <----Reg-Reply-----
      Figure 7: Request to access Home Agent from new Foreign Network

   If the mobile node is allowed to keep the home agent the AAAH then
   sends a HAR, which contains the Mobile IP Registration Request
   message data encapsulated in the MIP-Reg-Request AVP and the MIP-
   Home-Agent-Address AVP with home agent address, as well as any
   optional KDC session keys, to the AAAF in foreign network 1.
   Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA
   AVP from AMR and include it in the HAR when a third foreign domain is

   involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP

   for policy decisions, such as determining if the FA-HA Key should be
   encrypted or not. Upon reception the AAAF in foreign network 1 will
   forward the HAR to the Home Agent if its local policy allows such
   service. If the AAAF does not permit such service, it MUST return a
   DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

   If the AAAH local policy determines that the MN-HA Key must be
   encrypted and no security association is known to the home agent, the

   AAAH MUST send the HAR to the AAAF in foreign network 1, which
   originally assigned the HA in foreign network 1, by including its
   identity in the Destination-Host AVP.

   When the AAAF receives a HAA, the AAAF will forward the HAA back to
   the AAAH.  If successful, the HAA MUST include the MIP-Home-Agent-
   Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send

   back an AMA to the AAAF in foreign network 2.

   If the old Foreign Network does not permit the use of its Home Agent
   when the Mobile Node moves to a new foreign network, the AAAH or AAAF

   MUST return an AMA with the Result-Code AVP set to
   DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
   Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile

   Node with an appropriate error. The Mobile Node MAY attempt to
   request that a new Home Agent and Address be allocated. When the AAAH

   transmits such an error, it MUST issue a Diameter Abort-Session-
   Request message to the Home Agent to enable it to release any
   resources. "

Added to section 2.1  AA-Mobile-Node-Request:

"2.1  AA-Mobile-Node-Request

   The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field

   set to 260 and the 'R' bit set in the Command Flags field, is sent by

   an attendant, acting as a Diameter client, to a server in order to
   request the authentication and authorization of a Mobile Node.  The
   Foreign Agent (or Home Agent in the case of a co-located Mobile Node)

   uses information found in the Registration Request to construct the
   following AVPs that are to be included as part of the AMR:

          ...
          home agent NAI (MIP-Home-Agent-Host AVP)
          home AAA server NAI (Destination-Host AVP [DIAMBASE])

  ...

   If the mobile node includes the home agent NAI and the home AAA
   server NAI [AAANAI], the foreign agent MUST include the MIP-Home-
   Agent-Host AVP and the Destination-Host AVP in the AMR.

  ..."

Added to section 4.0:

"
   MIP-Home-Agent  348  4.12     Grouped    | M  |  P  |    |  V  | Y  |

   Host                                     |    |     |    |     |    |
"

Added a new grouped AVP:

"4.12 MIP-Home-Agent-Host AVP

   The MIP-Home-Agent-Host AVP (AVP Code TBD)if of type Grouped,
   and contains the identity of the assigned Home Agent.
   If present in the AMR, the AAAH MUST copy the MIP-Home-Agent-Host
   AVP into the HAR.

      MIP-Home-Agent-Host ::= < AVP Header: 348 >
                               { Destination-Realm }
                               { Destination-Host }
                             * [ AVP ] "

Added new text to section 5.3 :

" 5.3  Distributing the Mobile-Home Session Key

  ...

   If the home agent is in the home realm, then AAAH can directly encode

   the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include
   that AVP in the HAR message for delivery to the home agent.

   If, on the other hand, the home agent is to be allocated in the
   visited realm, the AAAH transmits the HAR to the foreign home agent,
   where, prior to delivery to the home agent, it is perused by the AAAF

   hosting the home agent. If the session key needs to be encrypted the
   AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data
   AVP using the security association with the home agent or with the
   AAAF associated with the home agent. If no security association is
   known the home agent, the AAAH will check if a security association
   can be established using DSA messages defined in the CMS application
   [CMS] with the originating host found in the MIP-Originating-Foreign-

   AAA AVP and if the DSA establishment is successful, the AAAH will
   encrypt the MIP-HA-to-MN Key AVP with the established security
   association. On the other hand, if no security association exists and

   the DSA establishment fails, the AAAH MUST return a Result-Code AVP
   with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

  ... "