Internet Draft Madjid Nakhjiri draft-nakhjiri-radius-mip4-00.txt Motorola Labs Category: Internet draft Kuntal Chowdhury Expires: August 2005 Starent Networks Avi Lior Bridgewater systems February 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 RFC 3668. 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 Internet-Draft will expire on August 8, 2005. 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 those providing key management and authentication services during a Nakhjiri et. al. Expires û August 2005 [Page 1] RADIUS Mobile IPv4 extensions February 2005 mobile nodeÆs registration process with MN-AAA authentication extension. Although Diameter Mobile IP application is being specified to support the needs of Mobile IPv4 from the AAA infrastructureÆs point of view, 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 Co-located mobile nodes....................................4 3.2 Registration through a Foreign Agent.......................7 4. RADIUS entity requirements....................................11 4.1 RADIUS server and routing requirements....................11 4.2 Mobile IP agent requirements..............................12 5. Attributes....................................................13 5.1 Attribute List............................................24 6. Diameter compatibility considerations.........................25 7. IANA considerations...........................................25 8. Security considerations.......................................25 9. References....................................................26 Acknowledgments..................................................27 Author's Addresses...............................................27 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 and its mobility agents. These trust relationships include, among other things, keys that are shared between the mobile node and these agents. Nakhjiri et. al. Expires û August 2005 [Page 2] RADIUS Mobile IPv4 extensions February 2005 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 is currently working on 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, 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) A Mobile IP home agent that is responsible for generating and keeping a binding between mobile nodeÆs permanent home address and its care of address. Foreign Agent (FA) Nakhjiri et. al. Expires û August 2005 [Page 3] RADIUS Mobile IPv4 extensions February 2005 A Mobile IP Foreign agent that is responsible for serving the mobile node in foreign networks. 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 not in the home 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 mentioned hence forth. In this document the terms AAAF and AAAH refer to RADIUS servers. 3. Protocol Overview In this section we will provide an overview of how a Mobile IP agent and a RADIUS server can interact during a mobile node registration process, to perform registration, authentication and key distribution. There may be cases, where more than one type of mobile IP agent is involved in Mobile IPv4 signaling, since Mobile IPv4 allows two types of care of addresses (CoA) for the mobile nodes: 1) When the MN acquires a collocated CoA (CcoA), it registers directly with the HA without the interaction of any Mobile IP foreign agents. 2) 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 use the FA based CoA for communications. The FA forwards the registration to the HA for processing. 3.1 Co-located mobile nodes 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 MN can authenticate its registration to the HA directly. However, when this MSA does not exist, the HA must outsource the authentication to the AAA infrastructure. However, this outsourcing is only possible when the MN has a pre-established security association with the AAA infrastructure (MN-AAA key). The HA may reside in the mobile nodeÆs home domain, in which case HA can reach the AAAH directly or the HA may reside in a foreign domain, Nakhjiri et. al. Expires û August 2005 [Page 4] RADIUS Mobile IPv4 extensions February 2005 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 Mobile IP 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: Co-located Mobile Nodes MN HA AAAH Server | Reg Req. | | | ---------> | | | | Access Request | | | ----------------------> | | | Access Accept (key mtrl)| | | <-----------------------| |Reg Rep. | | | <--------- | | Figure 1b: Mobile IP and RADIUS messaging for co-located MNs. 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 follows Authenticator = MD5( 0 || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || 237 octets of zeros) Nakhjiri et. al. Expires û August 2005 [Page 5] RADIUS Mobile IPv4 extensions February 2005 (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 to preserve interoperability). The use of challenge in co-located case is not required.) . The Mobile IP home agent (HA) receives a registration request (RRQ) and builds a RADIUS Access Request message and includes the following attributes into the message. The attributes included inside parentheses are optional. Note that the HA hashes the RRQ along with some other information before forming the MIP-HASH-RRQ to adhere to RADIUS attribute size limitation (253 bytes). This is explained in the attributes section. Note that, the MIP-feature-vector attribute includes a list of flags indicating a variety of information to the AAA server. RADIUS-Access Request { User-Name (MIP-MN-NAI or MIP-MN-HoA), NAS-IP (MIP-HA-IP address or MIP-HA-NAI) MIP-HASH-RRQ, MIP-MN-AAA-SPI, MIP-MN-AAA-Authenticator, MIP-feature-vector Message-Authenticator (80)} . The AAAH verifies the authentication data, by computing the MN- AAA-Authenticator value (using MIP-HASH-RRQ and MIP-MN-AAA-SPI) and comparing to what received in MIP-MN-AAA-Authenticator attribute. If there is a match, the AAAH generates the MN-HA key to be distributed to the HA, the nonce to be distributed to the MN for MN-HA key derivation and sends a RADIUS Access Accept packet to the Mobile IP home agent. The access accept packet includes the attributes listed below: RADIUS Access Accept { MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, Encrypted [MIP-MN-HA-key], MIP-MN-HA-nonce, MIP-MN-HA-ALGID, MIP-MN-HA-REP, MIP-MN-HA-MSA-LIFE Message-Authenticator (80) } . In case of authentication failure, the AAAH generates a RADIUS Access-Reject packet. . The HA receives the RADIUS Access Accept, retrieves the key material from the attributes (MIP-MN-HA key) for itself and builds the HA to MN MSA using and MN to HA MSAs, using the MIP- Nakhjiri et. al. Expires û August 2005 [Page 6] RADIUS Mobile IPv4 extensions February 2005 HA-to-MN SPI and MIP-MN-to-HA SPI, MIP-MN-HA-ALGID, MIP-MN_HA- REP and MIP-MN-HA-MSA-LIFE. Reception of RADIUS Access Accept is a sign of successful MN authentication. Thus, the HA processes the Mobile IP RRQ and generates a Mobile IP registration reply (RRP). The home agent also extracts the nonce for the MN and includes it in a MN-HA-key generation nonce reply extension, calculates an MN-HA Authentication extension based on the HA-to- MN SPI and received MN-HA key. . The MN extracts the nonces from the RRP, derives the MN-HA key and verifies 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 +--------+ | AAAF |---------------------->| AAAH | | | | | | server |< ---------------------|server | +--------+ Access Accept +--------+ ^ | ^ | Access | | Access Access | | Access Request | | Accept Request | | Accept | V | V +--------+ RRQ +---------+ RRQ +----------+ | Mobile | ------->| Foreign | ------------------->| Home | | Node | RRP | Agent | RRP | Agent | | |<--------| |<--------------------| | +--------+ +---------+ +----------+ Figure 2a. Mobile IP and RADIUS entities when FA-based CoAs are used. Nakhjiri et. al. Expires û August 2005 [Page 7] RADIUS Mobile IPv4 extensions February 2005 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) | | | | -----------> | | | | Acc. Accept | | | |(key mtrl for HA) | | |(RRP) |< -----------------| | RRP |<------- | | | | < -------- | | | | Figure 2b- Mobile IP and RADIUS messaging when FA-based CoAs are used . An MN being served by an FA, with whom the MN does not have an MSA, forms a registration request (RRQ) including MN-AAA authentication extension and MN-HA-key-generation-nonce-request, MN-FA-key-generation-nonce-request [MIPKEYS] and challenge extensions [RFC 3012] 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 and extracts the necessary information from the RRQ to form the attributes to be included in a RADIUS Access Request message. The FA sends this request towards the AAA infrastructure (either AAAF or to AAAH directly). The FA calculates a hash of the RRQ as follows and Nakhjiri et. al. Expires û August 2005 [Page 8] RADIUS Mobile IPv4 extensions February 2005 inserts in MIP-HASH-RRQ. 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. The FA need to also create the SPIs for any MSAs for which it requests key material from AAA server. The following attributes are included in this request: RADIUS-Access Request { User-Name (MIP-MN-HoA or MIP-MN-NAI) NAS-IP (MIP-FA-IP-address MIP-HA-IP-address (or MIP-FA-NAI if the HA address is all 1s or all 0s), MIP-MN-AAA-SPI, MIP-MN-FA challenge, MIP-HASH-RRQ, MIP-MN-AAA-Authenticator, MIP-feature-vector 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: Authenticator = MD5( High-order byte from Challenge || Key || Value of MIP-HASH-RRQ || Least-order 237 bytes from Challenge) . The AAAH compares this value with what it has received in MIP- MN-AAA-Authenticator attribute from FA. If authentication is successful, the AAAH generates the FA-HA key (if required), the MN-FA key and the MN-FA nonce for MN (for MN-FA MSA) and sends a RADIUS Access-Accept message including the following attributes to the FA RADIUS Access Accept { Encrypted [MIP-FA-HA key], MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-FA-HA-ALGID, MIP-FA-HA-MSA-LIFE, Encrypted [MIP-MN-FA key], MIP-MN-to-FA-SPI, MIP-FA-to-MN-SPI, MIP-MN-FA-MSA-LIFE, MIP-MN-FA-ALGID, Message-Authenticator (80) } Nakhjiri et. al. Expires û August 2005 [Page 9] RADIUS Mobile IPv4 extensions February 2005 . The FA retrieves the MN-FA key, FA-HA key and other materials related to MN-FA MSAs and FA-HA MSAs from the received Access- Request. The FA builds the MSA with the HA and relays the initial registration request including the MN-AAA Authentication extension to the HA. In this message, the FA appends 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. . 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 builds the hash of the RRQ and HA sets the appropriate flags within the MIP-feature-vector attribute to request keys from the AAAH for the HA-MN-MSA and HA-FA-MSA. RADIUS-Access Request { User-Name (MIP-MN-NAI or MIP-MN-HoA) NAS-IP (MIP-HA-NAI or MIP-HA-IP address), MIP-FA-IP address, MIP-MN-FA challenge, MIP-MN-AAA-SPI, MIP-MN-AAA-Authenticator, MIP-FA-to-HA-SPI, MIP-FA-HA-Authenticator, 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 validates the FA-HA authenticator first. If the FA-HA authentication is successful, the AAAH proceeds to validate the MN-AAA authenticator, using MN-AAA SPI (MIP-MN-AAA-SPI attribute). After validating the MN-AAA authenticator, 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. RADIUS Access Accept { Encrypted [MIP-FA-HA key], MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-FA-HA-ALGID, Nakhjiri et. al. Expires û August 2005 [Page 10] RADIUS Mobile IPv4 extensions February 2005 MIP-FA-HA-MSA-LIFE, Encrypted [MIP-MN-HA key], MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, MIP-MN-HA-nonce, MIP-MN-HA-ALGID, MIP-MN-HA-REP, MIP-MN-HA-MSA-LIFE MIP-MN-FA-nonce, MIP-MN-FA-ALGID, MIP-MN-FA-REP, MIP-MN-FA-MSA-LIFE, Message-Authenticator (80) } . The HA retrieves the key materials and the keys from the attributes included in the RADIUS access Accept message from the AAAH and builds a Mobile IP registration reply for the mobile node. The HA includes MN-FA-nonce and 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 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. 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). Therefore upon receiving the Access-Request packets 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 packet. An Access-Request packet which does not contain a Message-Authenticator (80) MUST be silently discarded. Nakhjiri et. al. Expires û August 2005 [Page 11] RADIUS Mobile IPv4 extensions February 2005 Message-Authenticator (80) SHOULD also be included in the Access- Accept packet. 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. 4.2 Mobile IP agent requirements In this document both the FA and HA operate as a client of RADIUS. 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 means when sending RADIUS Access Requests, the HA and FA may send their own IP addresses inside NAS-IP attribute instead of MIP-HA-IP-address and MIP-FA-IP-address attributes (suggested in this document), respectively. 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 required for Mobile IP signaling. In roaming situations, RADIUS servers typically route the Access- Request using the User-Name(1) attribute which 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- 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. Nakhjiri et. al. Expires û August 2005 [Page 12] RADIUS Mobile IPv4 extensions February 2005 Once the Message-Authenticator (80) attribute has been validated, the Mobile-IP agent decrypts the protected attributes as per RFC2868. 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 . User-name (Mobile node NAI) MIP-MN-NAI 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 Node NAI Type To be assigned by IANA Length > 3 String Mobile NodeÆs NAI The MN-NAI is used for routing of RADIUS packets and security database lookup. However, Mobile IP signaling does not mandate the use of MN-NAI extension when the MN has an HoA. When the MN does not have an HoA (RFC 3344 section 3.6), and sets the HoA field in the registration request to all 0s or all 1s, the MN-NAI extension becomes mandatory. . 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile NodeÆs Home IPv4 address Type To be assigned by IANA Length 6 Address Nakhjiri et. al. Expires û August 2005 [Page 13] RADIUS Mobile IPv4 extensions February 2005 Mobile NodeÆs Home IPv4 address When NAI extension is not added to the registration requests, MNÆs 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-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Æs Ipv4 Address Type To be assigned by IANA Length 6 Address Home AgentÆs 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 0.0.0.0 or 255.255.255.255), then this attribute is used in RADIUS access request. This attribute is required when FA-HA AE is used. The Address field MUST be populated with the destination address of the received RRQ at the HA. At the FA this attribute MAY not be used in the Access-Request. . MIP-HA-NAI 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 NAI Type To be assigned by IANA Length > 3 String Home AgentÆs NAI In case the MN supports AAA NAI processing [RFC 3846] the MN may add the MIP-HA-NAI. Nakhjiri et. al. Expires û August 2005 [Page 14] RADIUS Mobile IPv4 extensions February 2005 . 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Æs Ipv4 Address Type To be assigned by IANA Length 6 Address Foreign AgentÆs 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 SHA1 (Preceding Mobile IP data from MN-AAA AE|| Type, Subtype (if present), Length, SPI) This attribute includes an MD5 or SHA1 hash version of Mobile IP registration request (similar to RFC 3012 section 8). This attribute is carried by the Access request. . 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 û August 2005 [Page 15] RADIUS Mobile IPv4 extensions February 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 Node SPI Type To be assigned by IANA Length > 3 String 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 û August 2005 [Page 16] RADIUS Mobile IPv4 extensions February 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile IPv4 feature vector Type To be assigned by IANA Length 3 String Mobile IPv4 feature vector This an 8-bit flag vector, where each set flag represent 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 Reserved 4 Home-Agent-Requested (MN has not been allocated an HA) 8 reserved 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 û August 2005 [Page 17] RADIUS Mobile IPv4 extensions February 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Mobile Node to Home Agent SPI Type To be assigned by IANA Length > 3 String 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home agent to Mobile Node SPI Type To be assigned by IANA Length > 3 String Nakhjiri et. al. Expires û August 2005 [Page 18] RADIUS Mobile IPv4 extensions February 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 û August 2005 [Page 19] RADIUS Mobile IPv4 extensions February 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-ALGID 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 Algorithm identifier Type To be assigned by IANA Length > 3 String 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. . MIP-MN-HA-REP 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 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. . MIP-MN-HA-MSA-LIFE Nakhjiri et. al. Expires û August 2005 [Page 20] RADIUS Mobile IPv4 extensions February 2005 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 | Integer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home Agent-Mobile Node MSA life time Type To be assigned by IANA Length > 3 Integer 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-LIFE Similar to MIP-MN-HA-MSA-LIFE . MIP-MN-FA-ALGID Similar to MIP-MN-HA-ALGID . 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign agent to Home agent SPI Type Nakhjiri et. al. Expires û August 2005 [Page 21] RADIUS Mobile IPv4 extensions February 2005 To be assigned by IANA Length > 3 String Foreign agent to Home Agent to 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Home agent to Foreign agent SPI Type To be assigned by IANA Length > 3 String 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 String FA-HA key Nakhjiri et. al. Expires û August 2005 [Page 22] RADIUS Mobile IPv4 extensions February 2005 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-ALGID 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-LIFE 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 | Integer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Foreign Agent-Home Agent MSA life time Type To be assigned by IANA Length > 3 Integer 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 û August 2005 [Page 23] RADIUS Mobile IPv4 extensions February 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.1 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. MIP-HA-NAI, MIP-HA-IP address, MIP-FA-IP address, MIP-HASH-RRQ, MIP-MN-FA challenge, MIP-MN-AAA-Authenticator, MIP-feature-vector Message Authenticator (80)} MIP-MN-AAA-SPI, MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, MIP-FA-to-HA-SPI, MIP-HA-to-FA-SPI, MIP-MN-to-HA SPI, MIP-HA-to-MN-SPI, Encrypted[MIP-MN-HA-key], Encrypted [MIP-FA-HA key], Nakhjiri et. al. Expires û August 2005 [Page 24] RADIUS Mobile IPv4 extensions February 2005 MIP-MN-HA-nonce, MIP-MN-FA-nonce, MIP-MN-HA-ALGID, MIP-FA-HA-ALGID, MIP-MN-FA-ALGID, MIP-MN-HA-REP, MIP-MN-FA-REP, MIP-MN-HA-MSA-LIFE MIP-FA-HA-MSA-LIFE, MIP-MN-HA-MSA-LIFE MIP-MN-FA-MSA-LIFE 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 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. This would impose new complexity on the Diameter-RADIUS interaction. On the other hand, we tried to follow the Diameter attribute type definition model to extent possible for RADIUS. One exception is the fact that RADIUS does not have any support for grouped attributes and that is why attributes relating to authentication extensions and security associations are designed with a ôflatö structure. 7. IANA considerations This draft introduces new RADIUS attributes. Therefore there is need for defining new attribute type numbers by IANA. 8. Security considerations Mobile IP (RFC 3344) specifies a Foreign-Home authentication extension for protecting the integrity of messaging between FA and HA. This is especially important when the FA directly forwards the registration request to the HA. However, this extension is optional, Nakhjiri et. al. Expires û August 2005 [Page 25] RADIUS Mobile IPv4 extensions February 2005 since for scalability reasons, it is difficult to establish SAs between large number of FAs and Has. Not using this extension opens the door for DoS attacks launched by the FA against the HA. 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 through 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 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 is used by the MN for generating the key out of the nonce: key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || home address}) Which means two things: 1) AAA server needs the MN home address to generate the keys to be sent to mobility agents. 2) We are assuming SHA1 is used as a hash function as opposed to MD-5 when tighter security is required. 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. [MIP4CHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions", draft-ietf-mip4-rfc3012bis-00.txt., November 2003. Nakhjiri et. al. Expires û August 2005 [Page 26] RADIUS Mobile IPv4 extensions February 2005 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", IETF work in progress, Internet draft, IETF, draft-ietf-mip4- aaa-key-06.txt, June 2004. [DIAMIP] P. Calhoun, C. Perkins, ôDiameter Mobile IP applicationö, IETF work in progress, draft-ietf-aaa-diameter-mobileip-18.txt, May 2004. [RADTUNN], G. Zorn, Et. Al., ôRADIUS Attributes for Tunnel Protocol Supportö, IETF, RFC 2868, June 2000. 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 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 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 Nakhjiri et. al. Expires û August 2005 [Page 27] RADIUS Mobile IPv4 extensions February 2005 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 August 8, 2005. Nakhjiri et. al. Expires û August 2005 [Page 28]