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]