RADIUS Mobile IPv4 extensions July 2005 Internet Draft Madjid Nakhjiri draft-nakhjiri-radius-mip4-01.txt Motorola Labs Category: Internet draft Kuntal Chowdhury Expires: January 2006 Starent Networks Avi Lior Bridgewater systems Kent Leung Cisco Systems July 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 becomes 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 Internet-Draft will expire on January 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Nakhjiri et. al. Expires - January 2006 [Page 1] RADIUS Mobile IPv4 extensions July 2005 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 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....................................5 3.2 Registration through a Foreign Agent.......................8 4. RADIUS entity requirements....................................12 4.1 RADIUS server and routing requirements....................12 4.2 Mobile IP agent requirements..............................13 5. Attributes....................................................15 5.1 Attribute List............................................27 6. Diameter compatibility considerations.........................29 7. IANA considerations...........................................29 8. Security considerations.......................................29 9. References....................................................30 Acknowledgments..................................................30 Author's Addresses...............................................31 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 Nakhjiri et. al. Expires -- January 2006 [Page 2] RADIUS Mobile IPv4 extensions July 2005 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 -- January 2006 [Page 3] RADIUS Mobile IPv4 extensions July 2005 A Mobile IP home agent that is responsible for generating and keeping a binding between mobile nodeÆs 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. 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 how a mobility agent and a RADIUS server can interact during a mobile node registration process, to perform registration, authentication and key distribution. 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 registers directly with the HA without the interaction of a Mobile IP foreign agent. 2-a) 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 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. Nakhjiri et. al. Expires - January 2006 [Page 4] RADIUS Mobile IPv4 extensions July 2005 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 HA can authenticate MNÆs 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 mobile nodeÆs home domain, in which case 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 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 CoAs with R bit=0. Nakhjiri et. al. Expires - January 2006 [Page 5] RADIUS Mobile IPv4 extensions July 2005 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) (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.). . 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 includes the following attributes into the message. 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. If the HA finds a MN-NAI extension inside the RRQ with a routable NAI value, the HA includes the NAI value inside the user-name attribute. If the HA finds a routable HoA for the MN, the HA includes the value inside the MIP-MN-HoA. If the HA does not find an acceptable user identifier (NAI or HoA or other forms acceptable for RADIUS routing) for the MN, the HA shall reject the RRQ. If the HA finds an acceptable IP address inside the HA IP address field of the RRQ, the HA will include that inside the MIP-HA-IP address attribute. If, on the other hand, 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. The NAS ID 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). 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 Nakhjiri et. al. Expires - January 2006 [Page 6] RADIUS Mobile IPv4 extensions July 2005 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 { , (preferably MIP-MN-NAI from RRQ) , (from RRQ) (from RRQ) NAS-ID (as per RADIUS specifications) 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. The AAAH then sends a RADIUS Access Accept message to the home agent. The Access Accept message 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-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. . 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 the MIP-HA-to-MN SPI and MIP-MN- to-HA SPI, MIP-MN-HA-ALGORITHMID, MIP-MN_HA-REPLAY and MIP-MN- HA-MSA-LIFETIME. 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 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. Nakhjiri et. al. Expires - January 2006 [Page 7] RADIUS Mobile IPv4 extensions July 2005 . The MN extracts the nonces from the RRP, derives the MN-HA key [MIPKEYS] 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(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: Nakhjiri et. al. Expires - January 2006 [Page 8] RADIUS Mobile IPv4 extensions July 2005 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 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-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 inserts in MIP-HASH-RRQ. The FA may set the appropriate flags Nakhjiri et. al. Expires - January 2006 [Page 9] RADIUS Mobile IPv4 extensions July 2005 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 create the SPIs for any MSA for which it requests key material from AAA server. If the HA IP address is available from RRQ, the FA includes it inside MIP-HA-IP-address attribute (Note that when the RRQ includes ALL_ZEROS_OR_ONES in the HA field, the HA field will not convey the HA identity to the AAA server). Otherwise the FA inserts the HA NAI from the RRQ inside the MIP-HA-ID attribute. Note that at least one of MIP-HA-IP-address and MIP- HA-ID MUST be present for identification of the HA at the AAA server. The FA includes its own identifier (e.g. NAI) inside the NAS-ID. The following attributes are included in this request: RADIUS-Access Request { , (preferably MIP-MN-NAI from RRQ) , (from RRQ) (from RRQ if available), (as per RADIUS specification) NAS-ID (as per RADIUS specification) (from RRQ) 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, Nakhjiri et. al. Expires - January 2006 [Page 10] RADIUS Mobile IPv4 extensions July 2005 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) } . 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- Accept. 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. Note, if an HA-FA-MSA exists, the FA 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. RADIUS-Access Request { (MIP-MN-NAI) NAS-ID (HA ID as per RADIUS specification) , , (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 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 Nakhjiri et. al. Expires - January 2006 [Page 11] RADIUS Mobile IPv4 extensions July 2005 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-ALGORITHMID, MIP-FA-HA-MSA-LIFETIME, Encrypted [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) } . 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 Nakhjiri et. al. Expires - January 2006 [Page 12] RADIUS Mobile IPv4 extensions July 2005 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 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. When the HA acts as a RADIUS NAS, the HA examines the contents of the RRQ. If the HA deems the information (such as included HoA, or NAI, or lack thereof) inadequate for RADIUS routing, the HA rejects the request without creating RADIUS messaging. The details of the underlying policies for this decision are outside scope of this document. Note that 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). If a RADIUS forwarding server does not have enough information to route the packet, it shall send an Access Reject towards the NAS. If a RADIUS server does not have enough information to identify the user for authentication purposes, the server MUST send an Access Reject. 4.2 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 Nakhjiri et. al. Expires - January 2006 [Page 13] RADIUS Mobile IPv4 extensions July 2005 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. 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, or use a different NAI or identifier to populate the User-Name attribute according the network policies. 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 - January 2006 [Page 14] RADIUS Mobile IPv4 extensions July 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. 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 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 User Name Type 1 (per RFC 2865) Length > 3 String User-Name This is the same as User-Name attribute defined in RFC 2865. The preferable value for User-Name attribute is NAI for the MN extracted from the MN-NAI extension within Mobile IP RRQ. It should be noted that 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_ZEROS_OR_ONES, 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 Nakhjiri et. al. Expires - January 2006 [Page 15] RADIUS Mobile IPv4 extensions July 2005 Mobile NodeÆs Home IPv4 address Type To be assigned by IANA Length 6 Address 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-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Æs IPv4 care of address Type To be assigned by IANA Length 6 Address Mobile NodeÆs 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Æs Ipv4 Address Type To be assigned by IANA Length 6 Address Nakhjiri et. al. Expires - January 2006 [Page 16] RADIUS Mobile IPv4 extensions July 2005 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 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. . NAS_IP 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 NAS-IP Type 4 Length 6 address The IPv4 address of the mobility agent, acting as the RADIUS NAS. . NAS_ID 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 NAS-ID Type 32 Length > 3 String 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. Nakhjiri et. al. Expires - January 2006 [Page 17] RADIUS Mobile IPv4 extensions July 2005 . 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 . 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 Nakhjiri et. al. Expires - January 2006 [Page 18] RADIUS Mobile IPv4 extensions July 2005 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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]. Nakhjiri et. al. Expires - January 2006 [Page 19] RADIUS Mobile IPv4 extensions July 2005 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 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 Nakhjiri et. al. Expires - January 2006 [Page 20] RADIUS Mobile IPv4 extensions July 2005 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 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 Nakhjiri et. al. Expires - January 2006 [Page 21] RADIUS Mobile IPv4 extensions July 2005 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 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 Nakhjiri et. al. Expires - January 2006 [Page 22] RADIUS Mobile IPv4 extensions July 2005 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 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 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. Suggested values: 1 MD5 2 HMAC-MD5 3 SHA1 . MIP-MN-HA-REPLAY Nakhjiri et. al. Expires - January 2006 [Page 23] RADIUS Mobile IPv4 extensions July 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 | 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: 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. Nakhjiri et. al. Expires - January 2006 [Page 24] RADIUS Mobile IPv4 extensions July 2005 . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Nakhjiri et. al. Expires - January 2006 [Page 25] RADIUS Mobile IPv4 extensions July 2005 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 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. Nakhjiri et. al. Expires - January 2006 [Page 26] RADIUS Mobile IPv4 extensions July 2005 . 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. . 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 Nakhjiri et. al. Expires - January 2006 [Page 27] RADIUS Mobile IPv4 extensions July 2005 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. User-Name, NAS-ID, NAS-IP, MIP-MN-HoA, MIP-MN-CoA, MIP-HA-ID, MIP-FA-ID, 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-FA SPI, MIP-FA-to-MN-SPI, Encrypted [MIP-MN-HA-key], Encrypted [MIP-MN-FA-key], Encrypted [MIP-FA-HA key], MIP-MN-HA-nonce, MIP-MN-FA-nonce, MIP-MN-HA-ALGORITHMID, MIP-FA-HA-ALGORITHMID, MIP-MN-FA-ALGORITHMID, MIP-MN-HA-REPLAY, MIP-MN-FA-REPLAY, MIP-MN-HA-MSA-LIFETIME MIP-FA-HA-MSA-LIFETIME, MIP-MN-FA-MSA-LIFETIME Nakhjiri et. al. Expires - January 2006 [Page 28] RADIUS Mobile IPv4 extensions July 2005 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, the way Diameter does. 7. IANA considerations This draft introduces new RADIUS attributes. Therefore there is need for defining new attribute type numbers by IANA. 8. Security considerations 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 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 Nakhjiri et. al. Expires - January 2006 [Page 29] RADIUS Mobile IPv4 extensions July 2005 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-03.txt., December 2004. [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", IETF, RFC 3957, March 2005. [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. Nakhjiri et. al. Expires - January 2006 [Page 30] RADIUS Mobile IPv4 extensions July 2005 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 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, Nakhjiri et. al. Expires - January 2006 [Page 31] RADIUS Mobile IPv4 extensions July 2005 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 - January 2006 [Page 32]