RADIUS Mobile IPv4 extensions October 2005 Internet Draft Madjid Nakhjiri draft-nakhjiri-radius-mip4-02.txt Motorola Labs Category: Internet draft Kuntal Chowdhury Expires: May 2006 Starent Networks Avi Lior Bridgewater systems Kent Leung Cisco Systems October 2005 RADIUS Mobile IPv4 extensions Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with section 6 of BCP 79. 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 Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. This Internet-Draft will expire in May, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv4 specifies mechanisms that need assistance from a AAA server and a AAA infrastructure. Examples of such mechanisms are Nakhjiri et. al. Expires - May 2006 [Page 1] RADIUS Mobile IPv4 extensions October 2005 those providing key management and authentication services during a registration process of the mobile node with MN-AAA authentication extension. Although Diameter Mobile IP application is being specified to support the needs of Mobile IPv4 from the point of view of the AAA infrastructure, such support does not exist within RADIUS framework. This document defines the RADIUS attributes that provide support for Mobile IPv4 operation. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction...................................................2 2. Terminology and Assumptions....................................3 3. Protocol Overview..............................................4 3.1 Direct registration to Home Agent..........................5 3.2 Registration through a Foreign Agent.......................9 4. RADIUS entity requirements....................................14 4.1 RADIUS client requirements................................14 4.2 RADIUS server and routing requirements....................15 4.3 Mobile IP agent requirements..............................16 5. Attributes....................................................18 5.1 Use of existing attributes................................18 5.2 Suggested attributes for RADIUS-Mobile support............19 5.3 Attribute List............................................31 6. Diameter compatibility considerations.........................32 7. IANA considerations...........................................33 8. Security considerations.......................................33 9. References....................................................34 Acknowledgments..................................................35 Author's Addresses...............................................35 1. Introduction Mobile IP provides routing services to the nodes that need to change their IP address due to mobility [MIPv4]. To help setting up such routing services, the mobile node (MN) needs to engage in an authenticated registration message exchange with the Mobile IP agents. Message authentication is performed by inclusion of specific authentication extensions to the mobility registration messages and relies on existence of trust relationships between the mobile node Nakhjiri et. al. Expires - May 2006 [Page 2] RADIUS Mobile IPv4 extensions October 2005 and its mobility agents. These trust relationships include, among other things, keys that are shared between the mobile node and these agents. Many times such trust does not exist in advance and hence there is a need for dynamic key management methods in conjunction with Mobile IP signaling. Mobile IPv4 working group has developed extensions for the registration process to allow the MN and mobility agents to request assistance from the AAA server in authentication [MIP4CHAL] and creation of the key material [MIPKEYS], all based on the pre- established trust relationship between the MN and its home AAA server. However, on the AAA side, currently only Diameter provides specification for interaction with Mobile IP agents [DIAMIP]. The available RADIUS support for Mobile IP is mostly vendor proprietary and lacks support for interoperability between vendors. The goal of this document is to provide a specification for IETF RADIUS attributes supporting Mobile IPv4. 2. Terminology and Assumptions The scope of this draft is to introduce RADIUS functionality and attributes, designed to support Mobile IP registration for roaming within or beyond the administrative domain of the mobile node. The design in this document also serves inter-domain scenarios in which both a foreign AAA server (AAAF) and the home AAA server (AAAH) are involved. However, to keep the scenario discussions simple we treat the entire AAA infrastructure as consisting of a AAAF and a AAAH, but note that in the multi-domain scenario, the operation may involve a number of AAA proxies (AAA nodes operating between AAAF and AAAH) to provide Mobile IP-RADIUS interaction for a roaming mobile node. A critical assumption in this draft is that the MN shares a key, called MN-AAA key with its home RADIUS server (AAAH). MN-AAA key The MN-AAA key is the basis for the creation of all the keys that are created dynamically between MN and its mobility agents. Mobility Security Association (MSA) The security associations that are created as a result of Mobile IP-AAA signaling are called mobility security association (MSA)[MIPKEYS]. Home agent (HA) Nakhjiri et. al. Expires - May 2006 [Page 3] RADIUS Mobile IPv4 extensions October 2005 A Mobile IP Home Agent that is responsible for generating and keeping a binding between mobile node home address and its care of address. Foreign Agent (FA) A Mobile IP Foreign agent that is responsible for serving the mobile node in foreign networks. Mobile IP Agent (MA) Mobile IP Agent: Refers to HA or FA or both. Home AAA server (AAAH) The AAAH is a RADIUS server that operates in the home network. The home network is the network that holds the user record. Foreign AAA server (AAAF) The AAAF is a RADIUS server that acts as a "forwarding server", forwarding RADIUS packets to the AAAH. The AAAF resides in the same domain that hosts the FA in the foreign network or hosts the HA when the HA is also in the foreign network. Other Broker AAA ‘‘proxy servers’’ may exist between the AAAF and the AAAH. The role of these "proxy servers" is not germane to this document and will not be discussed henceforth. ALL_ZEROs_OR_ONES: This means an IP address set to either 0.0.0.0 or 255.255.255.255. In this document the terms AAAF and AAAH refer to RADIUS servers. 3. Protocol Overview In this section we will provide an overview of a preferred method on how a mobility agent and a RADIUS server can interact during a mobile node registration process, to perform registration, authentication and key distribution. Different standard developing organizations (such as 3GPP2 and WiMAX) may have alternative signaling procedures to implement Mobile IP-RADIUS interaction, depending on their architecture or trust assumptions. Our main objective is to standardize a set of RADIUS attributes to provide support for such activities. Depending on the type of Care-of Address and the mobility agents used during Mobile IPv4 registration there are two possible cases to consider: 1) When the MN acquires a co-located CoA (CCoA), it performs a direct registration with the HA without the interaction of a Mobile IP foreign agent. 2a) When the MN acquires a CoA from a Mobile IP foreign agent (FA) on the foreign network, the MN must register through the FA and Nakhjiri et. al. Expires - May 2006 [Page 4] RADIUS Mobile IPv4 extensions October 2005 use the FA based CoA for Mobile IP registration. The FA forwards the registration to the HA for processing. b) When the MN acquires a CCoA but the FA requires the MN to register via the FA (R-bit set in Agent Advertisement), the MN must send the registration request to the FA. The FA forwards the registration messages to/from the HA. 3.1 Direct registration to Home Agent In the case where the MN acquires a co-located CoA (CCoA), the MN registers its CCoA with the HA directly. When the MN has a mobility security association (MSA) with the HA, the HA can authenticate MN registration directly. However, when this MSA does not exist, the HA needs to outsource the authentication to the AAA infrastructure. Note that, this outsourcing requires a pre-established security association between MN and the AAA server (MN-AAA key). The HA may reside in the home domain of the mobile node. In such cases, the HA can reach the AAAH directly or the HA may reside in a foreign domain, which means the HA must reach the AAAH via the AAA infrastructure. In the following picture we do not show the AAA infrastructure (AAAF) that routes this messaging to the AAAH, since it does not impact the discussion in this draft. The HA in this model acts as a conversion point, turning Mobile IP registration messages into RADIUS messages and vice versa. +--------+ | AAAH | | | | server | +--------+ ^ | Access | | Access Request | | Response | v +--------+ RRQ +---------+ | Mobile | -------------> | Home | | Node | RRP | Agent | +--------+ <------------ +---------+ Figure 1a: Direct registration with HA Nakhjiri et. al. Expires - May 2006 [Page 5] RADIUS Mobile IPv4 extensions October 2005 MN HA AAAH Server | Reg Req. | | |---------> | | | | Access Request | | | ------------------------> | | | Access Accept (key mtrl)| | | <-------------------------| |Reg Rep. | | | <---------| | Figure 1b: Mobile IP and RADIUS messaging for direct registration. The operation is as follows: . The Mobile Node creates a registration request (RRQ) that includes MN-AAA Authentication extension and various key generation nonce request extensions [MIPKEY]. The latter extensions are included by the MN to request key material that is needed for establishment of MSA between the MN and the Mobile IP HA. The former extension is included to help the AAAH to authenticate the MN on behalf of the HA as Authenticator = MD5( 0 || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || 237 octets of zeros) (Note: the 0 octets in the authenticator for the co-located case are inserted instead of the octets used from the challenge in the FA-based CoA case [MIP4CHAL] to preserve interoperability). The use of challenge in co-located case is not required.). . Upon receiving a registration request (RRQ), the home agent (HA) examines the contents of the RRQ. If the HA finds the construction of RRQ acceptable, and is acting as a RADIUS NAS, it builds a RADIUS Access Request message and deals with the information within the RRQ as described in section for generic consideration for Mobile IP agents (section 4.3). The following shows the complete list of attributes included in the RADIUS Access Request formed by the HA. When forming the MIP-feature- vector attribute for co-located MNs, the HA shall set the ‘‘Co- located Mobile Node’’ flag as well as other appropriate flags to indicate the request from MN for keying material. The values insides parentheses following the attributes represent recommended attribute values. For more details on the recommendations, the reader is referred to section on Mobile IP agent requirements (4.2). Attributes included inside ‘‘<>’’ are optional. However, note that at least one of User-Name or MIP- MN-HoA MUST be present. Nakhjiri et. al. Expires - May 2006 [Page 6] RADIUS Mobile IPv4 extensions October 2005 RADIUS-Access Request { , (1) (MN NAI, when available in RRQ) , (from RRQ, when not ALL_ZEROs_OR_ONES) (from RRQ, when available) NAS-ID (32, as per RADIUS specifications) MIP-MA-Type (1 to indicate client as HA) MIP-HASH-RRQ, (see section 6 on Diameter compatibility) MIP-MN-AAA-SPI, MIP-MN-AAA-Authenticator, MIP-feature-vector (with co-located MN flag set) Message-Authenticator (80)} . The AAAH verifies the authentication data, by computing the MN- AAA-Authenticator value (as described in section 4.2) and comparing to what received in MIP-MN-AAA-Authenticator attribute. After successful authentication, the AAAH prepares the RADIUS Access Accept to be sent to the HA as follows -The User-Name or MIP-HA-HoA attribute (depending on presence) copied from the Access-Request. -If the ‘‘MN-HA-Key-Nonce-Request’’ flag was set in the MIP- feature-vector attribute in the RADIUS Access Request, the AAAH looks up the SPI value in the MIP-MN-AAA-SPI attribute to index the key generation method to derive the MN-HA key in accordance to RFC 3957. The following attributes are included in the Access Accept to convey the information in the MSA: MIP-MN-AAA-SPI, MIP-MN-to-HA-SPI, MIP-HA-to-MN-SPI, MIP-MN-HA-key (for the HA), MIP-MN-HA-Nonce (for the MN), MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY, MIP-MN-HA-MSA- LIFETIME. -If the ‘‘Mobile-Node-Home-Address-Requested’’ flag in MIP- feature-vector attribute in RADIUS Access Request was set, the AAAH includes the MIP-MN-HoA attribute for the assigned Home Address, which may not be the same as the hint in the MIP-MN-HoA attribute of the Access Request message. -If the ‘‘Home-Agent-Requested’’ flag in MIP-feature-vector attribute in RADIUS Access Request was set, the AAAH includes the MIP-HA-IP attribute for the assigned Home Agent. -Policy set on the AAAH may dictate that value for the flags (e.g. ‘‘Home Agent in Foreign network’’) in the attribute. The AAAH then sends a RADIUS Access Accept message to the home agent. The Access Accept message includes the attributes listed below ([] indicates need for specific security protection): RADIUS Access Accept { Nakhjiri et. al. Expires -- May 2006 [Page 7] RADIUS Mobile IPv4 extensions October 2005 MIP-MA-Type (1 to indicate client is an HA) MIP-MN-AAA-SPI MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, [MIP-MN-HA-key], MIP-MN-HA-Nonce, MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY, MIP-MN-HA-MSA-LIFETIME Message-Authenticator (80) } . In case of authentication failure or failure to identify the MN based on the provided User-Name or MN-HoA attributes, the AAAH generates a RADIUS Access-Reject packet. . Reception of RADIUS Access Accept is an indication of successful MN authentication. Thus, the HA processes the Mobile IP RRQ and generates a Mobile IP registration reply (RRP). The following describes how the RADIUS attributes are used in preparation of the RRP: -The value of the User-Name attribute is included in the MN- NAI Extension. -If the MIP-MN-HoA attribute exists, Home Address field in the RRP is set to the Address field value. -If the MIP-HA-IP attribute exists, the HA checks if it owns the IP address in the Address field. If so, the value is placed into the Home Agent field of the RRP. Otherwise, HA puts its IP address in the Home Agent field and the HA address from the RADIUS server in the Redirected HA Extension as specified in [MIPDYNHA]. -The values in the MIP-MN-to-HA SPI, MIP-MN-AAA-SPI, MIP-MN- HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP-MN-HA-MSA-LIFETIME provide the information in the ‘‘MN-HA Key Generation Nonce Reply Extension’’. Specifically, the String field in the MIP- MN-HA-Nonce attribute is extracted and put the MN-HA Key Generation Nonce Reply Extension. -The values in the MIP-HA-to-MN SPI, MIP-MN-to-HA SPI, MIP MN-HA-key, MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP- MN-HA-MSA-LIFETIME are used to create the MSA for MN on the Home Agent. The home agent also calculates an MN-HA Authentication extension based on the HA-to-MN SPI and received MN-HA key and includes in the RRP destined towards the MN. . If the MN-HA Key Generation Nonce Reply Extension is in the Registration Reply, the MN extracts the necessary information from the extension to derive the MN-HA key [MIPKEYS] and verify Nakhjiri et. al. Expires -- May 2006 [Page 8] RADIUS Mobile IPv4 extensions October 2005 the MN-HA authentication extension. If successful, the MN builds the MSA with the HA. 3.2 Registration through a Foreign Agent When the MN uses FA based CoAs, it needs to send its registration request to the FA. The block and message diagrams are shown in Figures 2a and 2b. +--------+ Access Request(2a) +--------+ | AAAF |---------------------->| AAAH | | | | | | server |< ---------------------|server | +--------+ Access Accept (3a) +--------+ (2) ^ | (3) (5) ^ | (6) Access | | Access Access | | Access Request | | Accept Request | | Accept | V | V +--------+RRQ (1) +---------+ RRQ (4) +----------+ | Mobile | ------->| Foreign | ------------------->| Home | | Node | RRP (8) | Agent | RRP (7) | Agent | | |<--------| |<--------------------| | +--------+ +---------+ +----------+ Figure 2a. Mobile IP and RADIUS entities when registration takes place through the FA (FA-based CoA or CcoA with R-bit set). The operation is as follows: MN FA HA AAAF AAAH -- --- ---- --- ---- | | | | | |Ad+Challenge | | | | | <--------- | | | | | RRQ-----. | | | | | |Access Request(RRQ)| Access | | | ----------------> | Req (RRQ)| | | | |-------. | | | | |Acc. Accpt| | | | |(key mtrl | | | | | for FA | | | | |< --------| | | Access Accept | | | | <-----------------| | | | RRQ | | | | | -------->| | | | | | Acc. Request(RRQ) | | | | -----------> | Nakhjiri et. al. Expires -- May 2006 [Page 9] RADIUS Mobile IPv4 extensions October 2005 | | | Acc. Accept | | | |(key mtrl for HA) | | |(RRP) |< -----------------| | RRP |<------- | | | | < -------- | | | | Figure 2b- Mobile IP and RADIUS messaging when registration takes place through the FA (FA-based CoA or CcoA with R-bit set). . An MN being served by an FA, with whom the MN does not have an MSA, forms a registration request (RRQ) including MN-HA-key- generation-nonce-request, MN-FA-key-generation-nonce-request [MIPKEYS], challenge extensions [MIP4CHAL] and MN-AAA authentication extension and sends this message to FA. The MN calculates the MN-AAA-Authenticator as follows Authenticator = MD5( High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge) . The FA checks the challenge [MIP4CHAL] and process the necessary information from the RRQ to form the attributes to be included in a RADIUS Access Request message as described in section 4.3. When creating the Access Request and forming the MIP-feature- vector attribute, the FA may set the appropriate flags within MIP-feature vector to indicate to the AAAH that it requires keys for FA-MN-MSA and FA-HA-MSA and perform the operation described by [MIPKEYS]. If the HA IP address field within the RRQ is not available, the FA inserts the HA NAI (if available) from the RRQ inside the MIP-HA-ID attribute. The FA includes its own identifier (e.g. NAI) inside the NAS-ID. The FA forms a RADIUS Access Request towards the AAA infrastructure(either AAAF or to AAAH directly) as follows RADIUS-Access Request { , (1) (MN NAI, when available in RRQ) , (from RRQ, when not ALL_ZEROs_OR_ONES) (from RRQ, when available) MIP-MA-Type (0 to indicate client is an FA) NAS-ID ((32, as per RADIUS specification) (from RRQ) MIP-MN-FA_Challenge, MIP-HASH-RRQ, MIP-MN-AAA-SPI, MIP-MN-AAA-Authenticator, Nakhjiri et. al. Expires -- May 2006 [Page 10] RADIUS Mobile IPv4 extensions October 2005 MIP-feature-vector (with co-located MN flag cleared) Message-Authenticator(80)} . The RADIUS Access request will eventually arrive at the AAAH through the AAA infrastructure. The AAAH server computes its own copy of the MN-AAA authenticator as follows (described in section 4.2): Authenticator = MD5( High-order byte from Challenge || Key || Value of MIP-HASH-RRQ || Least-order 237 bytes from Challenge) The challenge is the value within the MIP-MN-FA-Challenge. . The AAAH compares this value with what it has received in MIP- MN-AAA-Authenticator attribute from FA. After successful authentication, the AAAH prepares the RADIUS Access Accept as follows -The User-Name or MIP-HA-HoA attribute (depending on presence) copied from the Access-Request. -If the ‘‘MN-FA-Key-Nonce-Request’’ flag was set in the MIP- feature-vector attribute in the RADIUS Access Request, the AAAH looks up the SPI value in the MIP-MN-AAA-SPI attribute to index the key generation method to derive the MN-HA key in accordance to RFC 3957. The following attributes are included in the Access Accept to convey the information in the MSA: MIP-MN-AAA-SPI, MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI, MIP-MN-FA-key (for the FA), MIP-MN-FA-Nonce (for the MN), MIP-MN-FA-ALGORITHMID, MIP-MN-FA-REPLAY, MIP-MN-FA-MSA- LIFETIME. -If the ‘‘FA-HA-Key-Request’’ flag was set in the MIP-feature- vector attribute in the RADIUS Access Request, the following attributes are included in the Access Accept to convey the information in the MSA: MIP-MN-AAA-SPI, MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-MN-FA-key (for the FA), MIP-MN-FA- Nonce (for the MN), MIP-FA-HA-ALGORITHMID, MIP-FA-HA-MSA- LIFETIME. -Policy set on the AAAH may dictate that value for the flags (e.g. ‘‘Home Agent in Foreign network’’) in the attribute. The AAA server sends a RADIUS Access-Accept message including the following attributes to the FA ([] indicates need for specific security protection): RADIUS Access Accept { Nakhjiri et. al. Expires -- May 2006 [Page 11] RADIUS Mobile IPv4 extensions October 2005 MIP-MA-Type (0 to indicate client is an FA) (If HA is being delivered by AAA) [MIP-FA-HA key], MIP-MN-AAA-SPI MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-FA-HA-ALGORITHMID, MIP-FA-HA-MSA-LIFETIME, Encrypted [MIP-MN-FA key], MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI, MIP-MN-FA-Nonce, MIP-MN-FA-MSA-LIFETIME, MIP-MN-FA-ALGORITHMID, Message-Authenticator (80) } . Reception of RADIUS Access Accept by the FA is an indication of successful MN authentication. The FA needs to at this point extract the information regarding the MSAs with the MN and HA, build the SAs and follow the Mobile IP processing as defined in [MIPv4] and other specifications (such [MIPCHAL], [MIPKEYS], [MIPDYNHA], as set by policies). Processing of the attributes in the RADIUS Access Accept is as follows -If the MIP-HA-IP or MIP-HA-ID attributes exist, the FA uses the information for routing of the RRQ, while leaving the initial RRQ in tact (otherwise the MN-AAA-AE will not be computed by the AAA properly later) -If the MIP-MN-HoA attribute exists, the FA checks to see if there is a match with the MIP-MN-HoA received in RRQ (what if it is not?). -The values in the MIP-MN-to-FA SPI, MIP-MN-AAA-SPI, MIP-MN- HA-ALGORITHMID, MIP-MN-HA-REPLAY and MIP-MN-HA-MSA-LIFETIME provide the information in the ‘‘MN-HA Key Generation Nonce Reply Extension’’. Specifically, the String field in the MIP- MN-HA-Nonce attribute is extracted and put the MN-HA Key Generation Nonce Reply Extension. - The values of MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI, MIP-MN- FA-key (for the FA), MIP-MN-FA-Nonce (for the MN), MIP-MN- FA-ALGORITHMID, MIP-MN-FA-REPLAY, MIP-MN-FA-MSA-LIFETIME. are used to create the MSA for MN and for HA at the Foreign Agent. . After building the MSA with the HA, the relays the initial registration request including the MN-AAA Authentication extension to the HA. The FA May append the FA-HA Authentication extension with the authenticator computed using the received FA- HA key. The FA-HA authentication extension also includes the SPI that is copied from the received MIP-FA-to-HA-SPI attribute. Nakhjiri et. al. Expires - - May 2006 [Page 12] RADIUS Mobile IPv4 extensions October 2005 . Upon receiving the registration request from the FA, The HA creates a new RADIUS Access Request for the AAAH and includes the attributes shown below. The HA follows the guidelines in processing the RRQ fields as described in section 4.3 (including building hash from RRQ). The HA sets the appropriate flags within the MIP-feature-vector attribute to request keys and nonces from the AAAH for the HA-MN-MSA and HA-FA-MSA and clears the ‘‘co-located Mobile Node’’ flag. Note, if an HA-FA-MSA exists, the HA can simply verify the authenticator within FA-HA- Authenticator, without requesting the key for this MSA from the AAA server. This would mean the feature vector needs to be configured accordingly. Otherwise, the HA will store the FA-HA- Authentication extension for future verification. RADIUS-Access Request { (1) (MN NAI, when available in RRQ) , (from RRQ, when not ALL_ZEROs_OR_ONES) NAS-ID (HA ID as per RADIUS specification) MIP-MA-Type (1 to indicate client is an HA) , , (FA ID as per RADIUS specification) MIP-MN-FA challenge, MIP-MN-AAA-SPI, MIP-MN-AAA-Authenticator, MIP-FA-to-HA-SPI, MIP-HASH-RRQ, MIP-feature-vector, Message_Authenticator (80)} . The AAAH finds the FA-HA MSA based on the included MIP-FA-to-HA- SPI and/or MIP-MN-AAA-SPI. The AAAH verifies the MN-AAA Authenticator in the same manner as explained in section 4.2. If successful, the AAAH creates the MN-HA key and the corresponding nonces for MN-HA MSAs and sends a RADIUS Access Accept to the HA including the following attributes. Notes that both the all nonces for the MN (including those for MN-FA MSAs) are sent through this message to help the HA with one stop processing of the registration reply. The HA-FA and the MN-HA keys must be encrypted with the security association shared by the AAAH and HA ([] indicates need for specific security protection). RADIUS Access Accept { MIP-MA-Type (1 to indicate client is an HA) (If HA is being delivered by AAA) Nakhjiri et. al. Expires -- May 2006 [Page 13] RADIUS Mobile IPv4 extensions October 2005 [MIP-FA-HA key], MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-FA-HA-ALGORITHMID, MIP-FA-HA-MSA-LIFETIME, [MIP-MN-HA key], MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, MIP-MN-HA-Nonce, MIP-MN-HA-ALGORITHMID, MIP-MN-HA-REPLAY, MIP-MN-HA-MSA-LIFETIME MIP-MN-FA-Nonce, MIP-MN-FA-ALGORITHMID, MIP-MN-FA-REPLAY, MIP-MN-FA-MSA-LIFETIME, Message-Authenticator (80) } . Reception of RADIUS Access Accept by the HA is an indication of successful MN authentication. The HA retrieves the key materials and the keys from the attributes included in the RADIUS access Accept message from the AAAH. If the HA had received material regarding an MSA with the FA and had earlier received at FA-HA Authentication extension within the RRQ from FA, the AF validates the authenticator at this point [MIPKEYS]. The HA processes the RRQ and builds a Mobile IP registration reply for the mobile node. The HA includes MIP-MN-FA-Nonce and MIP-MN-HA- Nonce and related information into specified nonce reply extensions [MIPKEYS], builds MN-HA authentication extension and FA-HA Authentication extension (computed with received MN-HA key and FA-HA key, respectively) and sends the RRP to the FA. . The FA relays the RRP back to the MN as described in [RFC 3344] and [MIPKEYS] after building the MN-FA authentication extension when required. 4. RADIUS entity requirements 4.1 RADIUS client requirements User-Password (2), CHAP-Password(3), CHAP challenge(60), and ARAP- Password(70) MUST not be present in an Access-Request packet containing the attributes discussed in this document. As per RFC2869, packets that do not contain the above attribute MUST contain the Message-Authenticator (80). Nakhjiri et. al. Expires -- May 2006 [Page 14] RADIUS Mobile IPv4 extensions October 2005 As mentioned in section 8 and [MIPKEYS], the AAA server needs the MN identifier from the RADIUS Access Request sent by the RADIUS client. The MN identifier is either the MN's NAI, if present in the Registration Request, or the Home Address from the Registration Request otherwise. Hence the RADIUS Access Request MUST include at least one of the User-Name or MIP-MN-HoA attributes in the RADIUS Access Request. The NAS ID used in RADIUS Access Request packets SHALL be an identifier that complies with the RADIUS infrastructure (it may be the IP address that the HA uses towards the RADIUS server and different from the IP address included in MIP-HA_IP address). When the HA acts as a RADIUS NAS, the HA IP address included inside the optional MIP-HA-IP address attribute is retrieved from the initial RRQ (if included), while the NAS ID SHALL be an identifier that complies with the RADIUS infrastructure (it may or may not be the IP address that the HA uses towards the RADIUS server and different from the IP address included in MIP-HA-IP address). Besides, the attributes listed in this specification, the Access Request may include other RADIUS attributes such as NAS-IP-Address (4), Service-Type(6),etc required for RADIUS messaging. 4.2 RADIUS server and routing requirements The RADIUS servers are required to be able to understand and process the attributes described in this specification. The RADIUS server is also required to be able to support the authentication, key and nonce generation procedures described in this document. Upon receiving the Access-Request messages that contain Message- Authenticator (80) attribute, the RADIUS server MUST validate the value of the Message-Authenticator (80) as described in [RFC2869]. If the authenticator fails to validate, the RADIUS server MUST silently discard the Access-Request. An Access-Request which does not contain a Message-Authenticator (80) MUST be silently discarded. Message-Authenticator (80) SHOULD also be included in the Access- Accept message. The Message-Authenticator (80) calculation is described in RFC2869. In addition to the processing defined in this document after successful authentication the RADIUS server MAY include other authorization attributes in the Access-Accept packets that correspond to other features that are supported by the mobility agents. If a RADIUS forwarding server does not have enough information to route the packet, it shall send an Access Reject towards the NAS. Nakhjiri et. al. Expires - - May 2006 [Page 15] RADIUS Mobile IPv4 extensions October 2005 If a RADIUS server does not have enough information to identify the user for authentication purposes, the server MUST send an Access Reject. 4.3 Mobile IP agent requirements In this document both the FA and HA operate as RADIUS clients. They are responsible for passing user information to designated RADIUS servers, and acting on the responses received thereafter. In the context of RFC-2865 the FA and HA are NASes. This also means when sending RADIUS Access Requests, the HA and FA need to use their RADIUS-infrastructure-compatible identifier (can be an IP address) inside NAS-ID attribute. On the other hand, HA or FA need to specifically use the IP addresses that they use when interacting with the MN during MIP signaling inside MIP-HA-IP-address and MIP-FA-IP- address attributes. Since both FA and HA can act as NASes during the registration process, it is especially important for the NAS to include its IP address towards the MN (used for MIP signaling) in the RADIUS Access Requests, especially in cases where the MIP agent is using different IP interfaces towards the MN and towards the RADIUS server. This way, the server will know that it is receiving Access Requests from a Mobile IP capable NAS and it knows whether it is creating keys for an MN-FA or an MN-HA MSA. However, when the Access Request is sent from the FA to the AAAH, the IP address or NAI of the HA needs to be included to the message for authentication and key generation purposes. The use of MIP-HA-NAI and MIP-FA-NAI may be required for Mobile IP signaling. When receiving an RRQ from the MN, the Mobile IP agents (MA: HA or FA) and creating a RADIUS Access Request towards the AAA server, the MA will perform the following operations: -NAI-extension: If the HA finds a MN-NAI extension inside the RRQ with a NAI value, the HA includes the NAI value inside the User-Name attribute. -Home Address If the HA finds a routable HoA (other than ALL_ZEROs_OR_ONES) for the MN, the HA includes the value inside the MIP-MN-HoA. -Home Agent address field: If the HA finds a IP address other than ‘‘ALL_ZEROS_OR_ONES’’ inside the HA IP address field of the RRQ, the HA will include that inside the MIP- HA-IP address attribute. However, if the HA field is set to ‘‘ALL_ZEROS_OR_ONES’’ inside the RRQ from the MN, the HA SHALL set the value of ‘‘Home-Agent-Requested’’ inside MIP-feature- vector to indicate to the AAA server that MN has requested an HA assignment. -Requested HA extension: If an Requested HA Extension [MIPDYNHA] exists in the RRQ, the HA SHALL set the value of ‘‘Home-Agent-Requested’’ inside MIP-feature-vector to indicate to the AAA server that MN has requested an HA assignment. Nakhjiri et. al. Expires -- May 2006 [Page 16] RADIUS Mobile IPv4 extensions October 2005 - If the MN-HA Key Generation Nonce Request Extension is in the RRQ, then the HA sets the value of ‘‘MN-HA-Key-Nonce- Request’’ inside MIP-feature-vector attribute. Also, the HA includes the SPI value in the MN-AAA Authentication Extension to the MIP-MN-AAA-SPI attribute. -Registration Request: The Mobile IP registration request can include a large number of extensions, especially when key generation material is requested and authentication extensions including lengthy authenticators are present. To avoid the upper size limit for RADIUS attributes, the HA will create a hash of RRQ and inserts it in MIP-hash-RRQ attribute. A Foreign Agent that is forwarding an RRQ to the HA after having received a RADIUS Access Accept from the AAAH, will forward the initial RRQ to the HA as is, even though the Access Accept provides updated information (e.g. when the RRQ was missing HoA, while the AAAH has provided this information). This is to preserve the validity of the MN-AAA-AE added to the RRQ by the MN. Furthermore, note that creating a RADIUS Access Request based on a RRQ is within the discretion of HA or FA. If the MIP agent deems the RRQ or its contents (such as the HoA or HA-IP included in the RRQ) or lack thereof (such as NAI) inappropriate for processing, it MAY reject the RRQ without creating a RADIUS Access Request. For instance, in cases the RRQ does not include a routable HoA and lack MN-NAI extension, the HA may simply reject the RRQ. The details are outside the scope of this document. In roaming situations, RADIUS proxies typically route the Access- Request using the User-Name(1) attribute that contains an NAI [RFC 2486bis]. Therefore, Mobile IP Agents SHOULD populate the User- Name(1) attribute with the NAI value received in the RRQ when the MN- NAI extension is provided. When the MN-NAI extension is not provided, the User-Name (1) should be constructed using the MN HoA IP address. User-Password(2), CHAP-Password(3), CHAP challenge(60), and ARAP- Password(70) MUST not be present in an Access-Request packet containing the attributes discussed in this document. In these cases, the Mobile IP agent must include the Message-Authenticator (80) in the Access-Accept packet. The Message-Authenticator (80) is to be computed as per RFC2869. If the Access-Accept packet contains a Message-Authenticator (80) then the Mobile IP agent MUST validate the contents by computing the authenticator as describe in RFC2869. If the authenticator is not valid then the Mobile IP agent MUST silently discard the Access- Nakhjiri et. al. Expires -- May 2006 [Page 17] RADIUS Mobile IPv4 extensions October 2005 Accept packet. If the Mobile IP agent receives an Access-Accept packet that does not contain the Message-Authenticator it MUST silently discard the Access-Accept. Once the Message-Authenticator (80) attribute has been validated, the Mobile-IP agent decrypts the protected attributes as per RFC2868. In order to verify the value of authenticator within the MN-AAA- Authentication extension, the AAA server must follow the following expression: Authenticator = MD5( High-order byte from Challenge || Key || Value from MIP-Hash-RRQ attribute || Least-order 237 bytes from Challenge) Since the MIP-Hash-RRQ includes MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) The AAA server will in a sense follows the same calculation performed by the RADIUS clients (HA or FA): Authenticator = MD5( High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge) The challenge value is from MIP-FA-Challenge if present in the RADIUS Access Request or 0 octets, otherwise. This document does not address RADIUS accounting from the Mobile-IP agent and therefore whether RADIUS accounting packet are sent is not within scope of this document. 5. Attributes This section describes the full set of attributes required for RADIUS-Mobile IP interaction. Some of the attributes listed are already standardized (as noted by the attribute type value), while others will require standardization and IANA type assignments. 5.1 Use of existing attributes This subsection describes the use of those RADIUS attributes that are already standardized (e.g. by RFC 2865 and 3579). . User-Name (1)(per RFC 2865) Nakhjiri et. al. Expires -- May 2006 [Page 18] RADIUS Mobile IPv4 extensions October 2005 This is the same as User-Name attribute defined in RFC 2865. When an MN-NAI extension is available with Mobile IP RRQ, the NAI value is inserted into the value field of User-Name attribute. It should be noted that Mobile IP signaling does not mandate the use of MN-NAI extension when the MN has an HoA. . NAS_IP (4) (per RFC 2865) The IPv4 address of the mobility agent, acting as the RADIUS NAS. . NAS_ID (32) (per RFC 2865) The identifier (such as NAI) of the mobility agent, acting as the RADIUS NAS. In case the MN supports AAA NAI processing [RFC 3846] the MN may add the MIP-HA-NAI. 5.2 Suggested attributes for RADIUS-Mobile support This section describes a proposal for a set of new attributes for RADIUS-Mobile IP support. . MIP-MA-Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobility Agent Type Type To be assigned by IANA Length 3 Unsigned value 1 if the Mobile IP agent is an HA 0 if the Mobile IP agent is an FA Note: An alternative to creation of a new MIP-MA-Type is to extend the existing value set for attribute NAS-Port-Type (61) to include a value for HA and for FA as new NAS port values. TBD during RADIUS expert review. . MIP-MN-HoA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nakhjiri et. al. Expires -- May 2006 [Page 19] RADIUS Mobile IPv4 extensions October 2005 Name Mobile Node Home IPv4 address Type To be assigned by IANA Length 6 Address Mobile Node Home IPv4 address When NAI extension is not added to the registration requests, MN HoA IP address is used to identify the MN (key management draft [MIPKEYS, section 5]). The AAAH should be able to use HoA for identifying the MN, when NAI is not provided. . MIP-MN-CoA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile Node IPv4 care of address Type To be assigned by IANA Length 6 Address Mobile Node IPv4 care of address . MIP-HA-IP address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent Ipv4 Address Type To be assigned by IANA Length Nakhjiri et. al. Expires -- May 2006 [Page 20] RADIUS Mobile IPv4 extensions October 2005 6 Address Home Agent Ipv4 Address If the MN is assigned an HA and has included the IP address of the HA in its registration request (HA address other than ALL_ZEROS_OR_ONES), then this attribute is used in RADIUS access request. The Address field MUST be populated with the destination address of the received RRQ at the HA. This attribute is required when FA-HA AE is needed (the FA is requesting FA-HA-MSA keying material). For dynamic HA assignments via RADIUS, this field MAY be set to ALL_ZEROS_OR_ONES at the FA to indicate to the RADIUS server that the MN is requesting a dynamic HA assignment. It is however preferred that the FA uses the appropriate bit within the MIP- feature-vector attribute for that purpose. . MIP-HA-IP address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent IPv4 Address Type To be assigned by IANA Length 6 Address Home Agent Ipv4 Address . MIP-FA-IP address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign Agent IPv4 Address Type To be assigned by IANA Nakhjiri et. al. Expires -- May 2006 [Page 21] RADIUS Mobile IPv4 extensions October 2005 Length 6 Address Foreign Agent IPv4 Address . MIP-HASH-RRQ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 hashed Registration Request Type To be assigned by IANA Length >3 String MD5(Preceding Mobile IP data from MN-AAA AE|| Type, Subtype (if present), Length, SPI) This attribute includes an MD5 hash version of Mobile IP registration request (similar to RFC 3012 section 8). This attribute is carried by the Access request. The Mobile IP registration request can include a large number of extensions, especially when key generation material is requested and authentication extensions including lengthy authenticators are present. To avoid the upper size limit for RADIUS attributes, the HA or FA will create a hash of RRQ and insert it in MIP-hash-RRQ attribute. The AAA server uses the value of MIP-HASH_RRQ to calculate the authenticator in MN-AAA Authenticator as follows. Authenticator = MD5( High-order byte from Challenge || Key || Value of MIP-HASH-RRQ || Least-order 237 bytes from Challenge) The challenge is the value within the MIP-MN-FA-Challenge or 0. . MIP-FA challenge 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nakhjiri et. al. Expires -- May 2006 [Page 22] RADIUS Mobile IPv4 extensions October 2005 Name Mobile IPv4 Foreign Agent Challenge Type To be assigned by IANA Length > 3 String Mobile IPv4 Foreign Agent Challenge There is a Challenge Extension defined in RFC 3012 section 4. This attribute can be included in Access Request from FA to AAA and from the HA to the AAA, since it is used in the MN-AAA authentication extension. . MIP-MN-AAA SPI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 Node SPI Type To be assigned by IANA Length 6 Unsigned32 AAA SPI [MIPKEYS]. The AAA server uses this SPI to locate the security context needed to verify the MN-AAA authenticator calculated by the MN over the registration request data. The security context includes the MN-AAA key, and key related information and the algorithm used for calculation of authenticator fields. . MIP-MN-AAA-Authenticator 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 Mobile Node-AAA Authenticator value Type To be assigned by IANA Length > 3 Nakhjiri et. al. Expires -- May 2006 [Page 23] RADIUS Mobile IPv4 extensions October 2005 String MN-AAA authenticator value This attribute carries the value of MN-AAA-authenticator within the MN-AAA Authentication extension. The value is calculated based on a hash of RRQ and other information. The general expression (used for FA-based mobile nodes) is as follows Authenticator = MD5( High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge) For co-located mobile nodes, which register directly with the HA, no challenge value exists and therefore the values related to challenge are replaced with zero octets in the expression above. . MIP feature vector 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 feature vector Type To be assigned by IANA Length 6 Unsigned32 Mobile IPv4 feature vector This a flag vector of type Unsigned32, where each set flag represents a condition, such keys requested for FA or HA and so on. The flag values are as provided by Diameter, in order to facilitate interoperability between RADIUS and Diameter: 1 Mobile-Node-Home-Address-Requested (When MN does not have an HoA) 2 Home-Address-Allocatable-Only-in-Home-Realm 4 Home-Agent-Requested (when MN not allocated an HA) 8 Foreign-Home-Agent-Available 16 MN-HA-Key-Nonce-Request (key material for MN-HA MSA is requested) 32 MN-FA-Key-Nonce-Request 64 FA-HA-Key-Request 128 Home Agent in Foreign network Nakhjiri et. al. Expires -- May 2006 [Page 24] RADIUS Mobile IPv4 extensions October 2005 256 Co-located-Mobile-Node This attribute is added to the RADIUS Access Request message. For instance, when the MN has included a nonce generation request extension for MN-HA SA, the mobility agent (FA in FA CoA case and HA in CcoA case) sets the MN-HA key request flag in the MIP feature vector attribute included in the RADIUS Access Request message to indicate to the AAA that the MN requires nonces for MN-HA SA. The same goes for MN-FA nonce generation request extension from MN. When an FA is being used and FA requires keying material from the AAA server, the FA sets the FA-HA-key request flag. . MIP-MN-to-HA SPI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile Node to Home Agent SPI Type To be assigned by IANA Length 6 Unsigned32 Mobile node to Home Agent SPI This attribute can be included in the Access Request (from HA to AAAH) and Access Accept message (from AAAH to HA) and points to the MN-to-HA MSA that includes security context material (MN-HA Key Generation nonce, AAA SPI, Replay Method, Lifetime, and Algorithm Identifier) for the MN. This SPI is allocated by the HA. . MIP-HA-to-MN SPI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home agent to Mobile Node SPI Type To be assigned by IANA Length 6 Unsiged32 Nakhjiri et. al. Expires -- May 2006 [Page 25] RADIUS Mobile IPv4 extensions October 2005 Home Agent to Mobile Node SPI This attribute can be included in the Access Request (from HA to AAAH) and Access Accept message (from AAAH to HA) and points to the HA-to-MN MSA that includes security context material (MN-HA Key, Replay Method, Lifetime, and Algorithm Identifier??) for the HA. This SPI is allocated by the MN and is included in the initial Mobile- Home-Key generation nonce request extension within the RRQ generated by the MN. . MIP-MN-HA-key 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA key Type To be assigned by IANA Length > 3 String MN-HA key This attribute can be included in the Access Accept message from the AAAH to HA and includes MN-HA key for the HA to use when interacting with the MN. This attribute MUST be encrypted using procedures defined in RFC 2868 [RADTUNN]. . MIP-MN-HA-Nonce 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA nonce Type To be assigned by IANA Length > 3 String MN-HA nonce Nakhjiri et. al. Expires -- May 2006 [Page 26] RADIUS Mobile IPv4 extensions October 2005 This attribute can be included in the Access Accept message from the AAAH to HA and includes MN-HA nonce for the MN to use for calculating the MN-HA key used when interacting with the MN. . MIP-MN-HA-ALGORITHMID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA Algorithm identifier Type To be assigned by IANA Length 3 Unsigned8 MN-HA MSA algorithm identifier This attribute can be included in any message that includes the MIP- MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the algorithm that is used for MSA between MN and HA. Suggested values: 1 MD5 2 HMAC-MD5 3 SHA1 . MIP-MN-HA-REPLAY 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA replay mode Type To be assigned by IANA Length 3 String MN-HA MSA replay mode identifier This attribute can be included in any message that includes the MIP- MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the replay mode that is used for MSA between MN and HA. Suggested values: Nakhjiri et. al. Expires -- May 2006 [Page 27] RADIUS Mobile IPv4 extensions October 2005 1 timestamp 2 nonce . MIP-MN-HA-MSA-LIFETIME 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA life time Type To be assigned by IANA Length 6 Unsigned32 MN-HA MSA life time This attribute can be included in any message that includes the MIP- MN-to-HA SPI or MIP-HA-to-MN SPI and identifies the life time value for MSA between MN and HA. . MIP-MN-to-FA SPI Similar to MN-to-HA SPI. . MIP-FA-to-MN SPI Similar to HA-to-MN SPI. . MIP-MN-FA-key Similar to MIP-MN-HA-key. . MIP-MN-FA-Nonce Similar to MIP-MN-HA-Nonce . MIP-MN-FA-MSA-LIFETIME Similar to MIP-MN-HA-MSA-LIFETIME . MIP-MN-FA-ALGORITHMID Similar to MIP-MN-HA-ALGORITHMID . MIP-FA-to-HA-SPI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nakhjiri et. al. Expires -- May 2006 [Page 28] RADIUS Mobile IPv4 extensions October 2005 Name Foreign agent to Home agent SPI Type To be assigned by IANA Length 6 Unsigned32 Foreign agent to Home Agent SPI This attribute carries the SPI pointing to the security context between the FA and the HA for the HA. The SPI is allocated by the HA. The signaling in this draft does not require this attribute, since the SPI can be carried in Mobile IP extensions. . MIP-HA-to-FA SPI 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home agent to Foreign agent SPI Type To be assigned by IANA Length 6 Unsigned32 Home agent to Foreign agent SPI This attribute carries the SPI pointing to the security context between the FA and the HA for the FA. The SPI is allocated by the FA. This attribute is included in the access request from FA to AAAH and later in access accept from AAAH to HA. . MIP-FA-HA-key 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign agent to Home Agent to key Type To be assigned by IANA Length > 3 Nakhjiri et. al. Expires -- May 2006 [Page 29] RADIUS Mobile IPv4 extensions October 2005 String FA-HA key This attribute is sent to FA and to HA in an Access Accept messages from the AAAH to these agents. The key is used by FA and HA for integrity protection. This attribute MUST be encrypted using procedures defined in RFC 2868 [RADTUNN]. . MIP-FA-HA-ALGORITHMID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign Agent-Home Agent MSA Algorithm identifier Type To be assigned by IANA Length > 3 String FA-HA MSA algorithm identifier This attribute can be included in any message that includes the MIP- FA-to-HA SPI or MIP-HA-to-FA SPI and identifies the algorithm that is used for MSA between MN and HA. . MIP-FA-HA-MSA-LIFETIME 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Unsigned32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign Agent-Home Agent MSA life time Type To be assigned by IANA Length 6 Unsigned32 FA-HA MSA life time This attribute can be included in any message that includes the MIP- FA-to-HA SPI or MIP-HA-to-FA SPI and identifies the life time value for MSAs between FA and HA. Nakhjiri et. al. Expires -- May 2006 [Page 30] RADIUS Mobile IPv4 extensions October 2005 . MIP-FA-HA-Authenticator 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ string (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign Agent-Home Agent Authenticator value Type To be assigned by IANA Length > 3 (2+128) String FA-HA Authenticator This attribute is included in message from HA to AAAH for verification of authenticator added the FA for HA, when HA is not aware of the MSAs it shares with the FA. 5.3 Attribute List This list will be completed as an attribute table that includes information on the messages that are allowed to carry each attribute and whether each attribute must be protected in the next version of the draft. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name, 0-1 0 0 0 4 NAS-IP, 0-1 0 0 0 32 NAS-ID, 0-1 0-1 0 0 NA MIP-MA-Type 0-1 0-1 0 0 NA MIP-MN-HoA, 0-1 0-1 0 0 NA MIP-MN-CoA, 0-1 0 0 0 NA MIP-HA-ID, 0-1 0 0 0 NA MIP-FA-ID, 0-1 0 0 0 NA MIP-HA-IP address, 0-1 0 0 0 NA MIP-FA-IP address, 0-1 0 0 0 NA MIP-HASH-RRQ, 0-1 0 0 0 NA MIP-MN-FA challenge, 0-1 0 0 0 NA MIP-MN-AAA-Authenticator, 0-1 0 0 0 NA MIP-feature-vector 1 1 1 1 80 Message Authenticator 0-1 0-1 0 0 NA MIP-MN-AAA-SPI, 0 0-1 0 0 NA MIP-MN-to-HA SPI, 0 0-1 0 0 NA MIP-HA-to-MN-SPI, Nakhjiri et. al. Expires - - May 2006 [Page 31] RADIUS Mobile IPv4 extensions October 2005 0-1 0-1 0 0 NA MIP-FA-to-HA-SPI, 0 0-1 0 0 NA MIP-HA-to-FA-SPI, 0 0-1 0 0 NA MIP-MN-to-FA SPI, 0 0-1 0 0 NA MIP-FA-to-MN-SPI, 0 0-1 0 0 NA MIP-MN-HA-key, 0 0-1 0 0 NA MIP-MN-FA-key, 0 0-1 0 0 NA MIP-FA-HA key, 0 0-1 0 0 NA MIP-MN-HA-Nonce, 0 0-1 0 0 NA MIP-MN-FA-Nonce, 0 0-1 0 0 NA MIP-MN-HA-ALGORITHMID, 0 0-1 0 0 NA MIP-FA-HA-ALGORITHMID, 0 0-1 0 0 NA MIP-MN-FA-ALGORITHMID, 0 0-1 0 0 NA MIP-MN-HA-REPLAY, 0 0-1 0 0 NA MIP-MN-FA-REPLAY, 0 0-1 0 0 NA MIP-MN-HA-MSA-LIFETIME 0 0-1 0 0 NA MIP-FA-HA-MSA-LIFETIME, 0 0-1 0 0 NA MIP-MN-FA-MSA-LIFETIME 6. Diameter compatibility considerations Diameter Mobile IP application has defined new command codes for support of Mobile IP signaling such as, AA-Mobile node request (AMR), AA-Mobile Node answer (AMA), Home agent MIP-request (HMR), Home agent MIP-answer (HMA). RADIUS currently does not have any messages that correspond to these Diameter commands. However RADIUS provides the flexibility of defining new command codes. The solution in this draft is designed based on the assumption that the RADIUS community (and RADEXT) is not interested in defining new RADIUS messages hence we will be using RADIUS access request and RADIUS access accept for providing messaging from mobility agents to RADIUS server and vice versa. The following pictures show the Diameter messaging to support Mobile IP signaling as described in [DIAMIP]. +--------+ |Diameter| | server | +--------+ Diameter ^ |Diameter AMR | | AMA | | RRQ | V +--- + -----> +----+ | MN | RRP | HA | +----+ <----- +----+ Figure 3a Diameter messaging for co-located MNs Nakhjiri et. al. Expires -- May 2006 [Page 32] RADIUS Mobile IPv4 extensions October 2005 +-----+ Diameter HAR +--------+ | HA |-------------------->|Diameter| | |< -------------------|server | +-----+ Diameter HAA +--------+ ^ | Diameter | |Diameter AMR | | AMA | V +----+ RRQ +----+ | MN | ------->| FA | | | RRP (8) | | +----+<--------+----+ Figure 3b Diameter messaging for FA-based MNs Comparing the Diameter messaging (figure 2) with our suggestion for RADIUS messaging (figure 3), the following simple rules apply to Diameter to RADIUS translation, as long as the new MIP-MA-Type identifying the type the Mobile IP agent (FA or HA) is used. Diameter HAR <-> RADIUS Access Request Diameter HAA <-> RADIUS Access Accept/Reject (MIP-MA-Type=1) Diameter AMR <-> RADIUS Access Request Diameter AMA <-> RADIUS Access Accept/Reject (MIP-MA-Type=0) The attributes defined in this specification follow the Diameter AVP definition to the extent possible for RADIUS. Exceptions are cases where a Diameter AVP is of grouped type or potentially has a size that exceeds the RADIUS attribute size limit (253 byte). For grouped type Diameter AVPs, we simply convert each data field of the Diameter AVP into a separate RADIUS attribute. This is implemented for all the MSA-related AVP/ attributes. One specific such case is the use of Diameter MIP-Reg-Request AVP. For RADIUS we suggest hashing all the data in RRQ up to the MN- AAA-Authentication extension and including the hash inside MIP- HASH-RRQ to adhere to RADIUS attribute size limitation (253 bytes). This is explained in the attributes section as well as in the section dealing with RADIUS server considerations. 7. IANA considerations This draft introduces new RADIUS attributes. Therefore there is need for defining new attribute type numbers by IANA. 8. Security considerations Nakhjiri et. al. Expires -- May 2006 [Page 33] RADIUS Mobile IPv4 extensions October 2005 We recommend the use of the optional Mobile IP (RFC 3344) Foreign- Home authentication extension for protecting the integrity of messaging between FA and HA to protect the HA from DoS attacks launched by the FA. Another possible attack is DoS attacks by MNs using large numbers of Mobile IP RRQs. Therefore, we require that the FA implements the challenge response mechanism in RFC 3012 and forwards the challenge inside RRQ to the HA. Another security concern is on the distribution of keys from the AAA server to mobility agents. The AAAH creates and distributes keys for the Mobile IP agents and nonces for mobile nodes. The key transfer must happen in a secure manner. This means, the MSA-attributes including HA and FA keys must be encrypted with the security associations between the AAAH and the mobility agents. Such security association may be based on RADIUS shared secrets (hop by hop) or methods similar to those defined in [KEYWRAP] based on end-to-end SAs (possibly IPsec) between the AAAH and the mobility agents. For foreign agents, other trusted AAA servers (such as AAAF and AAAF-AAAH keys) may have to be involved. Also, it is important that the keys for each mobility agent are kept hidden from other mobility agents. For instance keys for FA must be kept secret from HA. This means the AAA server must have separate keys with each of the HA and FAs. On the other hand, the nonces generated by the AAA server, destined to the mobile can be transmitted in the clear. The MN-FA and MN-HA nonces are protected by the FA and HA authentications to the MN. However, to prevent man-in-the-middle tampering with the nonces in transit from AAAH to the HA and to FA to the MN, We recommend that the AAAH also authenticates the nonce-reply-extensions with the AAA SA it shares with the MN. Finally, we assume the following formula [MIPKEYS] is used by the MN for generating the key out of the nonce: Key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || MN identifier}) ,which means the AAA server needs the MN identifier from the RADIUS Access Request to generate the keys corresponding the nonces. For RADIUS threats and vulnerabilities please refer to the Security Section in RFC3579. 9. References [MIPv4] C. Perkins, IP Mobility Support, IETF, RFC 3344, August 2002. Nakhjiri et. al. Expires -- May 2006 [Page 34] RADIUS Mobile IPv4 extensions October 2005 [MIP4CHAL] C. Perkins, P. Calhoun, Mobile IP Challenge/Response Extensions, draft-ietf-mip4-rfc3012bis-04.txt., June 2005. [MIPKEYS] C. Perkins, P. Calhoun, AAA Registration Keys for Mobile IP, IETF, RFC 3957, March 2005. [MIPDYNHA] M. Kulkarni, A. Patel, K. Leung, ‘‘Mobile IPv4 Dynamic Home Agent Assignment’’, draft-ietf-mip4-dynamic-assignment-06.txt August 2005. [DIAMIP] P. Calhoun, C. Perkins, Diameter Mobile IP application, IETF, RFC 4004, May 2004. [RADTUNN], G. Zorn, Et. Al., RADIUS Attributes for Tunnel Protocol Support, IETF, RFC 2868, June 2000. [KEYWRAP], G. Zorn, Et. Al., RADIUS Attributes for Key Delivery, draft-zorn-radius-keywrap-08.txt. Acknowledgments The authors would like to give special thanks to Farid Adrangi for the initial discussions and recommendations on the attribute design work. The authors would also like to thank Charlie Perkins for consultation on the use of RFC 3012 procedures. Author's Addresses Madjid Nakhjiri Motorola Inc. Contact Email: Madjid.Nakhjiri@motorola.com Kuntal Chowdhury Starent Networks Contact Email: kchowdhury@starentnetworks.com Avi Lior Bridgewater systems Contact Email: avi@bridgewatersystems.com Kent Leung Cisco Systems Contact Email: kleung@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to Nakhjiri et. al. Expires -- May 2006 [Page 35] RADIUS Mobile IPv4 extensions October 2005 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. This Internet-Draft will expire on January 14, 2006. Nakhjiri et. al. Expires -- May 2006 [Page 36]